ArcGIS REST vs. SOAP API


27

Kiedy należy korzystać z interfejsu API REST ArcGIS Server w porównaniu z interfejsem SOAP API i odwrotnie? Jakie są zalety jednej strony nad drugą?

Na przykład usługa SOAP może być wykorzystana jako odwołanie do usługi w celu integracji z Visual Studio. Czy jest coś, co dałoby ci taki poziom integracji z REST?

Więcej informacji: ArcGIS GIS Services


3
Jeśli chcesz anulować zadanie GP, obecnie musisz użyć SOAP.
Kirk Kuykendall

Odpowiedzi:


18

To dobre pytanie. Chociaż lubię REST, nie widzę sposobu, aby żądać wartości Z i M dla geometrii. Wygląda na to, że jest to możliwe w przypadku SOAP przy użyciu obiektu PointN . Byłoby wspaniale, gdyby to pytanie ewoluowało i zawierało więcej różnic.

Innym czynnikiem jest to, co klienci muszą obsługiwać - jeśli to tylko Silverlight, SOAP jest o wiele bardziej atrakcyjny.

Opracowałem usługi SOE i GP, które wysyłają złożone obiekty przez Json.NET. Obiekty te są łatwo konsumowane przez Silverlight, ale wygląda na to, że klient javascript będzie miał znacznie trudniejszy czas .


12

REST - Reprezentatywne przekazanie stanu

REST zasadniczo oznacza, że ​​każdy unikalny adres URL reprezentuje jakiś obiekt. Możesz pobrać zawartość tego obiektu za pomocą HTTP GET, aby go usunąć, możesz następnie użyć POST, PUT lub DELETE, aby zmodyfikować obiekt (w praktyce większość usług używa do tego POST).

SOAP - Simple Object Access Protocol

SOAP jest najczęściej używany w aplikacjach korporacyjnych do integracji szerokiego typu i nie. aplikacji i innym trendem jest integracja ze starszymi systemami itp. Google konsekwentnie wdraża swoje usługi sieciowe przy użyciu SOAP (oprócz Bloggera)

SOAP wygrywa z GeoProcessing z ArcGIS Server +1 dla Kirka


Myślę, że „prosty” jest mylącą nazwą SOAP (może z wyjątkiem klikania kreatora VS, aby to zrobić). Wydaje się łatwiejsze w użyciu REST, ale ostatecznie zależy to od tego, jakich klientów potrzebujesz obsługiwać (jak powiedział Kirk powyżej).
Bratch

2
Google ma tylko pięć interfejsów API SOAP i 45 interfejsów API REST: programmableweb.com/apis/directory/…
scw

7

W przypadku poprzednich klientów patrzyliśmy na to od wieków, a dla nich długim i krótszym terminem było to, że SOAP ma zbyt dużo czasu na rozwój, a REST był łatwy do wdrożenia dla organizacji.

Można argumentować, że SOAP nie są tak naprawdę usługami internetowymi ...

Oto kilka argumentów dla ciebie:

MYDŁO / RESZTA



3

Coraz więcej osób przechodzi na usługi REST, ponieważ są one bardzo łatwe w użyciu i kodowaniu, podczas gdy SOAP jest bardzo oszczędny i powolny w porównaniu do REST. W niedalekiej przyszłości zobaczymy dużą migrację i (mam nadzieję), że SOAP umrze


Coraz więcej osób przenosi się do usług, które ich zdaniem są ODPOWIEDNIE, ale tak naprawdę nie są
nmtoken
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.