ArcGIS REST 및 SOAP API

ArcGIS Server REST API 와 SOAP API 중 어느 것을 사용하는 것이 적절한가 ? 다른 것보다 장점이 무엇이라고 생각하십니까?

예를 들어 SOAP 서비스는 Visual Studio에 통합하기 위해 서비스 참조로 사용될 수 있습니다. REST와의 통합 수준을 제공 할 수있는 것이 있습니까?

추가 정보 : ArcGIS GIS Services

좋은 질문입니다. REST를 좋아하지만 지오메트리에 Z 및 M 값을 요청하는 방법은 없습니다. PointN 객체를 사용하는 SOAP에서 가능해 보입니다 . 이 질문이 더 많은 차이점을 나열하도록 진화하는 것을 보는 것이 좋을 것입니다.

또 다른 요인은 클라이언트가 지원해야하는 것입니다. Silverlight 일 경우 SOAP가 훨씬 더 매력적입니다.

Json.NET을 통해 복잡한 객체를 보내는 SOE 및 GP 서비스를 개발했습니다. 이러한 객체는 Silverlight에서 쉽게 사용할 수 있지만 , 자바 스크립트 클라이언트가 훨씬 더 힘들 것 같습니다 .

REST-대표 상태 이전

REST는 기본적으로 각 고유 URL이 일부 객체를 나타냅니다. HTTP GET을 사용하여 해당 오브젝트의 컨텐츠를 가져 와서 삭제할 수 있습니다. 그런 다음 POST, PUT 또는 DELETE를 사용하여 오브젝트를 수정할 수 있습니다 (실제로 대부분의 서비스는이를 위해 POST를 사용합니다).

SOAP-단순 객체 액세스 프로토콜

SOAP는 주로 엔터프라이즈 응용 프로그램에서 광범위한 유형을 통합하고 사용하지 않습니다. 응용 프로그램 및 또 다른 추세는 레거시 시스템 등과 통합하는 것입니다. Google은 SOAP (Blogger 제외)를 사용하여 웹 서비스를 지속적으로 구현하고 있습니다.

Kirk의 ArcGIS Server +1에서 GeoProcessing으로 SOAP 승리

이전 클라이언트에서는이를 위해 오랜 기간 동안, 그리고 짧고 짧은 기간 동안 SOAP에서 개발 리드 타임이 너무 길고 REST가 조직에서 구현하기 쉽다는 점을 살펴 보았습니다.

SOAP는 실제로 웹 서비스가 아니라고 주장 할 수 있습니다 ...

다음은 몇 가지 주장입니다.

SOAP / REST

이제 ArcGIS REST API 10.1에서 작업을 취소하고 Z 및 M을 반환 할 수 있습니다.

GP 작업 제출 (현재 returnZ 및 returnM 옵션 사용)

GP 작업 취소

점점 더 많은 사람들이 사용하고 코딩하기가 쉬우면서 SOAP가 REST에 비해 매우 틱하고 느리기 때문에 REST 서비스로 이동하고 있습니다. 머지 않아 우리는 큰 마이그레이션을 보게 될 것이며 (희망스럽게도) SOAP는 죽을 것입니다