Jakie jest współczesne znaczenie SOAP

51

Ostatnio spotkałem się z usługą SOAP podczas mojego stażu w firmie finansowej w 2013 roku. To był czas, kiedy rozpocząłem karierę w branży IT. Pamiętam, że miałem trochę materiału do nauki o SOAP na jednym z moich kursów inżynierskich. Poza tym w trakcie mojej kariery nie korzystałem z SOAP.

Pytam o to, ponieważ pytanie „Różnica między SOAP a REST” pojawiło się w jednym z moich ostatnich wywiadów. Z tego co wiem (i co znalazłem w Google) SOAP jest protokołem ściśle powiązanym między klientem a serwerem w celu wymiany informacji, która jest ściśle związana z logiką biznesową. Natomiast REST to bardziej elastyczna architektura bezstanowa do przesyłania danych.

Czy ktoś może mnie poprawić, jeśli się mylę co do różnicy między SOAP a REST? Jakie jest współczesne znaczenie SOAP? Czy ludzie nadal opracowują nowe interfejsy API oparte na SOAP, czy to w większości jest już spuścizna?

Abhas Tandon
źródło
2
patrz także: Przyszłość SOAP, z REST
gnat
14
@gnat: Na ile warto, odpowiedzi na oba te pytania są okropne.
Robert Harvey,
7
Czy kiedykolwiek widziałeś usługę REST? Widzę tylko „usługi sieciowe, które w końcu nauczyły się, co oznaczają czasowniki HTTP”. Dlaczego nagle wywołujemy HTTP REST?
Luaan,
8
@Luaan: Nie ma w tym nic nagłego; ludzie od lat nadużywają terminu „REST”.
Lekkość ściga się z Monicą

Odpowiedzi:

58

REST jest rzeczywiście stylem architektonicznym. SOAP to protokół danych. To rozróżnienie jest ważne; nie można ich bezpośrednio porównać.

Głównym celem REST jest reprezentowanie zasobów w Internecie i zapewnienie mechanizmów ich wykrywania. Z kolei SOAP służy do przesyłania danych strukturalnych między komputerami i to wszystko, co naprawdę robi.

Pamiętaj, że tak naprawdę nie potrzebujesz usługi REST, aby utworzyć relację klient / serwer między dwoma komputerami w Internecie. Wszystko czego potrzebujesz to mechanizm, który przenosi JSON lub XML, a nawet nie potrzebujesz tego, jeśli chcesz być niezgodny ze wszystkimi innymi.

Niemniej jednak SOAP przestał być przychylny dla nowych, publicznie dostępnych interfejsów API, choć nadal jest powszechnie stosowany w aplikacjach B2B, ponieważ można z nim zdefiniować „umowę o dane”. Usługi sieciowe JSON mają tę zaletę, że są raczej lekkie i elastyczne, a ponieważ JavaScript rozpoznaje JSON natywnie, jest to naturalny wybór dla przeglądarek.

Ale tak naprawdę to nie ma wiele wspólnego z REST.

Dalsza lektura
Czy REST jest lepszy niż SOAP? (dobry artykuł, nawet jeśli niepoprawnie nazywa REST protokołem).
Model dojrzałości Richardsona

Robert Harvey
źródło
3
Powiedziałbym, że zabójczą funkcją usług internetowych JSON jest właśnie fakt, że przeglądarki mają słabą obsługę XML i SOAP, podczas gdy mają (prawie) natywną obsługę JSON. SOAP ma wiele do zrobienia, ale jeśli nie możesz wysyłać żądań AJAX przeciwko usłudze SOAP, jest martwa. Javascript / JSON stał najniższy wspólny mianownik w internecie, tak że trzeba ogromne korzyści, aby go nie używać, a SOAP nie jest , że o wiele lepiej.
Luaan,
3
@Luaan Nie powiedziałbym, że przeglądarki mają słabą obsługę XML. W rzeczywistości trudno jest uzyskać coś lepszego niż wykonanie XML HttpRequest i uzyskanie dostępu do atrybutu, który ma przeanalizowany DOM. Tyle, że jeśli chce się typowej struktury danych, a nie dokumentu, JSON jest po prostu bardziej odpowiedni, niezależnie od tego, czy korzystasz z przeglądarki, czy z innego środowiska.
André Paramés,
4
Wszystko czego potrzebujesz to mechanizm, który przenosi JSON lub XML, a nawet nie potrzebujesz tego, jeśli chcesz być niezgodny ze wszystkimi innymi. -1: Jeśli chcesz połączyć klienta z serwerem, potrzebujesz tylko dowolnego protokołu, który obie strony rozumieją, że nie ma to nic wspólnego z używaniem xml, JSON lub kompatybilnością ze wszystkimi innymi. Nawet użycie json lub xml nie gwarantuje, że jest kompatybilny ze wszystkimi, a nawet z kimś. Json i xml to tylko formaty danych, nic więcej.
Paul Wasilewski
6
@PaulWasilewski: Tak, tak powiedziałem. Nie rozłączaj się ze słowami. Jest powód, dla którego wszyscy używają JSON; to standard. Korzystanie z niego gwarantuje, że używasz czegoś, co jest rozpoznawalne dla innych.
Robert Harvey
3
@RobertHarvey, nie, to nie jest to, co napisałeś, może to miałeś na myśli. JSON jest standardem, więc co? CSV, bufory Protcol, BSON są znormalizowane, a także wiele innych. Więc powód, dla którego wszyscy używają JSON, jest różnorodny. I są nawet tacy, którzy używają JSON, ponieważ wszyscy używają JSON;)
Paul Wasilewski
29

REST jest znacznie bardziej ograniczony niż SOAP, co jest jego siłą i powodem jego popularności.

W SOAP zestaw dozwolonych operacji i zestaw dozwolonych typów danych jest zasadniczo nieograniczony. SOAP to protokół procedury zdalnej, którego używasz do ujawniania lokalnych interfejsów API w sieci bez utraty wierności. To spowodowało, że SOAP stał się popularny w środowiskach korporacyjnych, w których złożone systemy transakcyjne wymagały interakcji w sieci bez utraty wierności. To bogactwo możliwości jest również wadą SOAP, ponieważ sprawia, że ​​API SOAP są tak kłopotliwe w zrozumieniu i użyciu, że wymagają zautomatyzowanego oprzyrządowania w postaci bibliotek klienta WSDL i SOAP, aby nadać sens. Co więcej, ujawnienie pełnego bogactwa bazowego systemu jest nieatrakcyjne w publicznie dostępnych interfejsach API, w których chcesz zapewnić abstrakcje, które pozwolą ci rozwinąć bazowy system bez konieczności przerywania lub wersjonowania interfejsu API.

REST + JSON zyskał popularność szczególnie ze względu na swoją prostotę. Definiuje ograniczony zestaw operacji z ograniczonym zestawem typów danych, wymagając od projektanta interfejsu API ostrożnego zaprojektowania abstrakcji, które pasują do tego ograniczonego słownictwa i naprawdę przemyślają mapowanie domeny biznesowej na zasoby REST. Interfejs API REST jest łatwy do zrozumienia i łatwy w użyciu bez specjalnego oprzyrządowania. W przypadku publicznie dostępnego interfejsu API, w którym użytkownicy interfejsu API mogą mieć wszystkie poziomy umiejętności i wiedzy, jest to dokładnie to, czego chcesz, dlatego właśnie wszystkie interfejsy API widoczne w Internecie przechodzą na REST. SOAP jest przenoszony do sytuacji korporacyjnych, w których nadal istnieje potrzeba i potrzeba współdzielenia złożonych interfejsów API między systemami. Jednak,

Zasadniczo ludzie zdali sobie sprawę, że zestaw ograniczeń, które należy zastosować do projektu interfejsu API, aby interfejs API był prosty i wystarczająco abstrakcyjny, aby był łatwy w utrzymaniu i łatwy w użyciu, jest dokładnie zbiorem ograniczeń wprowadzanych przez REST, który skutecznie neutralizuje SOAP korzyści, które pozostawiają tylko swoje wady. Możesz zbudować uproszczony interfejs API za pomocą SOAP, ale nigdy nie będzie tak łatwy w użyciu jak REST, więc w praktyce każdy po prostu wybiera REST.

Joeri Sebrechts
źródło
4
Dobra stara debata na temat pisania statycznego i dynamicznego, yay: D Schludna i trudna kontra hacky i prosta, wojna, która nigdy się nie kończy.
Luaan,
@Luaan ... i dynamiczny zawsze wygrywa w przypadku wymiany danych. youtube.com/watch?v=ROor6_NGIWU
Jared Smith
6
@JaredSmith Nie zgadzam się zdecydowanie. Umowy powinny być przestrzegane, aby oba punkty końcowe poprawnie odwzorowały dane, jeśli możesz to zrobić poprzez publikację metadanych zamiast stron dokumentacji podatnych na błędy, dlaczego nie miałbyś tego zrobić?
drake7707
1
Praktyczny REST to protokół; Teza i religia to „styl architektoniczny”. Ta odpowiedź poprawnie porównuje praktyczny odpoczynek z praktycznym mydłem.
bmargulies
1
Twoja odpowiedź już pokazała, że ​​nie rozumiesz REST i komentujesz to podkreśla.
Paul Wasilewski
5

Nie można porównać REST i SOAP. REST to styl architektoniczny, a SOAP to protokół.

Niestety REST stał się potocznym synonimem usługi RESTful HTTP, co oznacza realizację architektury w stylu REST za pomocą protokołu HTTP jako (aplikacji).

REST opiera się na następujących zasadach (ograniczenia i elementy) (w nawiasach realizacja w RESTful HTTP) [1] .

  • Bezstanowy (HTTP jest protokołem bezstanowym)
  • Zasób (identyfikowany przez URI)
  • Jednolity interfejs (metody HTTP)
  • Reprezentacja (TYP MIME)
  • HATEOS (hiperłącza)
  • Pamięć podręczna (pamięć podręczna HTTP)

Z drugiej strony wiele osób ma na myśli mówiąc, że SOAP to usługa sieciowa oparta na WSDL i SOAP, które są częścią architektury usług sieciowych W3C [2] .

  • SOAP służy jako protokół do wymiany informacji (w zasadzie nazwa metody, parametry, zwracane wartości, typy danych, ...).
  • WSDL język definicji interfejsu opisujący usługę internetową.

Jakie jest współczesne znaczenie SOAP *?

SOAP jest standardem W3C i jest używany jako format wymiany informacji w serwisach internetowych W3C. Te usługi internetowe były - szczególnie podczas szumu SOA (archiwa zorientowane na usługi) około 2008 r. (+ - 3 lata) - i (niestety) są nadal wdrażane głównie w aplikacjach dla przedsiębiorstw.

Ma to kilka przyczyn. Wówczas RESTful HTTP nie był dobrze znany i został źle zrozumiany. Niestety, nadal jest źle rozumiany, spójrz na inne odpowiedzi

„[...] REST jest znacznie bardziej ograniczony niż SOAP [...].”

„Głównym celem REST jest reprezentowanie zasobów w Internecie [...].”

Ponadto SOAP (i WSDL) są częścią stosu protokołów usług sieciowych W3C, który zapewnia jeszcze więcej standardów wdrażania usługi internetowej.

Czy ludzie nadal opracowują nowe interfejsy API oparte na SOAP, czy to w większości jest już spuścizna?

Więc tak, nadal istnieją i będą w przyszłości systemy, które używają SOAP (przynajmniej w systemach korporacyjnych, głównie za drzwiami). Ale większość próbuje dziś zrobić „REST”.

Czy ktoś może mnie poprawić, jeśli się mylę co do różnicy między SOAP a REST?

Mówienie, że REST jest bardziej elastyczną bezstanową architekturą do przesyłania danych, nie jest dobrym wytłumaczeniem. Mówiąc prosto, REST to styl architektury ze specyficznymi ograniczeniami i elementami. Natomiast SOAP jest protokołem wymiany informacji.

Jak już napisałem, nie możesz ich porównać. Ale możesz porównać usługę WWW RESTful HTTP z usługą SOAP / WSDL.

Paweł Wasilewski
źródło
„Ale możesz porównać usługę WWW RESTful HTTP z usługą SOAP / WSDL”. Ale o to prosi OP. Czy ktoś już na to odpowiedział?
RoboJ1M