Czy REST jest lepszym podejściem do korzystania z usług WWW, czy jest SOAP? Czy są to różne narzędzia do różnych problemów? A może jest to kwestia niuansowa - to znaczy, czy na niektórych arenach jest nieco lepiej niż na innych, itp.?

Byłbym szczególnie wdzięczny za informacje o tych koncepcjach i ich związku ze światem PHP, a także o nowoczesnych aplikacjach internetowych wysokiej klasy.

Zbudowałem jeden z pierwszych serwerów SOAP, w tym generowanie kodu i generowanie WSDL, na podstawie oryginalnej specyfikacji, która była opracowywana, gdy pracowałem w Hewlett-Packard. NIE polecam używać SOAP do niczego.

Skrót „SOAP” to kłamstwo. To nie jest proste, nie jest zorientowane obiektowo, nie określa zasad dostępu. Jest to prawdopodobnie protokół. Jest to najgorsza specyfika Dona Boxa, a to całkiem niezły wyczyn, ponieważ to on popełnił „COM”.

W SOAP nie ma nic użytecznego, czego nie można zrobić z REST do transportu, a JSON, XML, a nawet zwykłego tekstu do reprezentacji danych. Dla bezpieczeństwa transportu możesz użyć https. W celu uwierzytelnienia podstawowe uwierzytelnianie. Na sesje są ciasteczka. Wersja REST będzie prostsza, bardziej przejrzysta, będzie działać szybciej i będzie zużywać mniej przepustowości.

XML-RPC wyraźnie określa protokoły żądania, odpowiedzi i błędu, a dla większości języków istnieją dobre biblioteki. Jednak XML jest cięższy niż potrzebujesz do wielu zadań.

REST to architektura, SOAP to protokół.

To pierwszy problem.

Możesz wysyłać koperty SOAP w aplikacji REST.

Samo SOAP jest właściwie dość proste i proste, a ponadto standardy WSS- *, które czynią go bardzo złożonym.

Jeśli Twoimi konsumentami są inne aplikacje i inne serwery, istnieje obecnie wiele sposobów obsługi protokołu SOAP, a podstawa przenoszenia danych to w zasadzie nowoczesne kliknięcie myszą w nowoczesnych IDE.

Jeśli Twoi konsumenci częściej są klientami RIA lub Ajax, prawdopodobnie będziesz potrzebować czegoś prostszego niż SOAP i bardziej rodzimego dla klienta (zwłaszcza JSON).

Pakiety JSON wysyłane przez HTTP niekoniecznie są architekturą REST, to tylko wiadomości na adresy URL. Wszystko doskonale wykonalne, ale idiom REST ma kluczowe elementy. Łatwo je jednak pomylić. Ale to, że mówisz o żądaniach HTTP, niekoniecznie oznacza, że ​​masz architekturę REST. Możesz mieć aplikację REST w ogóle bez HTTP (uwaga, jest to rzadkie).

Tak więc, jeśli masz serwery i klientów, którzy są „komfortowi” z SOAP, SOAP i stos WSS mogą ci dobrze służyć. Jeśli robisz więcej rzeczy ad hoc i chcesz lepiej współpracować z przeglądarkami internetowymi, to może również działać dobrze lżejszy protokół przez HTTP.

REST jest zasadniczo innym paradygmatem niż SOAP. Dobry odczyt na temat REST można znaleźć tutaj: Jak wyjaśniłem REST mojej żonie .

Jeśli nie masz czasu, aby go przeczytać, oto krótka wersja: REST to trochę zmiana paradygmatu, skupiając się na „rzeczownikach” i ograniczając liczbę „czasowników”, które możesz zastosować do tych rzeczowników. Jedynymi dozwolonymi czasownikami są „get”, „put”, „post” i „delete”. Różni się to od SOAP, w którym wiele różnych czasowników można zastosować do wielu różnych rzeczowników (tj. Wiele różnych funkcji).

W przypadku usługi REST cztery czasowniki są odwzorowywane na odpowiednie żądania HTTP, a rzeczowniki są identyfikowane za pomocą adresów URL. To sprawia, że ​​zarządzanie stanem jest znacznie bardziej przejrzyste niż w SOAP, gdzie często nie jest jasne, jaki jest stan na serwerze, a co na kliencie.

W praktyce jednak większość z nich zanika, a REST zwykle odnosi się tylko do prostych żądań HTTP, które zwracają wyniki w JSON , podczas gdy SOAP jest bardziej złożonym API, które komunikuje się poprzez przekazywanie XML. Obie mają swoje zalety i wady, ale z mojego doświadczenia wynika, że ​​REST jest zwykle lepszym wyborem, ponieważ rzadko, jeśli w ogóle, potrzebujesz pełnej funkcjonalności, którą otrzymujesz z SOAP.

Szybkie podsumowanie 2012 r. Pytanie:

Obszary, w których REST działa naprawdę dobrze, to:

• Ograniczona przepustowość i zasoby. Pamiętaj, że struktura zwracana jest naprawdę w dowolnym formacie (zdefiniowanym przez programistę). Ponadto można użyć dowolnej przeglądarki, ponieważ metoda REST używa standardowych czasowników GET, PUT, POST i DELETE. Ponownie pamiętaj, że REST może również używać obiektu XMLHttpRequest, który obsługuje większość współczesnych przeglądarek, co dodaje dodatkową premię AJAX.

• Całkowicie bezpaństwowe operacje.  Jeśli operacja musi być kontynuowana, REST nie jest najlepszym podejściem i SOAP może lepiej do niej pasować. Jeśli jednak potrzebujesz operacji bezstanowych CRUD (tworzenie, odczytywanie, aktualizowanie i usuwanie), to REST to właśnie ona.

• Sytuacje buforowania.  Jeśli informacje mogą być buforowane z powodu całkowicie bezstanowego działania metody REST, jest to idealne rozwiązanie, które obejmuje wiele rozwiązań w powyższych trzech.

Dlaczego więc miałbym rozważyć SOAP? Ponownie, SOAP jest dość dojrzały i dobrze zdefiniowany i ma pełną specyfikację. Podejście REST jest po prostu podejściem, które jest szeroko otwarte na rozwój, więc jeśli masz poniższe, SOAP jest doskonałym rozwiązaniem:

• Przetwarzanie i wywoływanie asynchroniczne.  Jeśli twoja aplikacja potrzebuje gwarantowanego poziomu niezawodności i bezpieczeństwa, SOAP 1.2 oferuje dodatkowe standardy zapewniające ten rodzaj działania. Rzeczy takie jak WSRM - WS-Reliable Messaging.

• Formalne umowy.  Jeśli obie strony (dostawca i konsument) muszą uzgodnić format wymiany, SOAP 1.2 podaje sztywne specyfikacje dla tego rodzaju interakcji.

• Operacje stanowe. Jeśli aplikacja potrzebuje informacji kontekstowych i zarządzania stanem konwersacyjnym, SOAP 1.2 ma dodatkową specyfikację w strukturze WS *, aby wspierać te rzeczy (bezpieczeństwo, transakcje, koordynacja itp.). Dla porównania, podejście REST zmusiłoby deweloperów do zbudowania tej niestandardowej hydrauliki.

http://www.infoq.com/articles/rest-soap-when-to-use-each

SOAP ma obecnie zaletę lepszych narzędzi, w których będą generować dużo kodu typu „płyta podstawowa” zarówno dla warstwy usługowej, jak i generowania klientów z dowolnego WSDL.

REST jest prostszy, może być łatwiejszy w utrzymaniu, leży w sercu architektury sieci, pozwala na lepszą widoczność protokołu i dowiedziono, że skaluje się do rozmiaru samej strony WWW. Niektóre frameworki pomagają tworzyć usługi REST, takie jak Ruby on Rails, a niektóre nawet pomagają w pisaniu klientów, takich jak ADO.NET Data Services. Jednak w przeważającej części brakuje wsparcia dla narzędzi.

SOAP jest użyteczny z punktu widzenia narzędzi, ponieważ WSDL jest tak łatwo wykorzystywany przez narzędzia. Dzięki temu możesz wygenerować klientów usługi sieci Web w swoim ulubionym języku.

REST działa dobrze na stronach internetowych AJAX. Jeśli upraszczasz swoje żądania, możesz wykonywać połączenia serwisowe bezpośrednio z JavaScript, co jest bardzo przydatne. Staraj się trzymać z daleka od przestrzeni nazw w XMLu odpowiedzi, widziałem, że przeglądarki się nimi dławią. Tak więc xsi: type prawdopodobnie nie zadziała dla ciebie, nie ma zbyt skomplikowanych schematów XML.

REST ma również lepszą wydajność. Wymagania procesora dotyczące kodu generującego odpowiedzi REST są zwykle niższe niż w przypadku struktur SOAP. A jeśli masz kaczki generacji XML ustawione w jednej linii po stronie serwera, możesz skutecznie przesyłać strumieniowo XML do klienta. Wyobraź sobie, że czytasz rzędy kursora bazy danych. Podczas czytania wiersza formatujesz go jako element XML i zapisujesz go bezpośrednio do odbiorcy usługi. W ten sposób nie musisz zbierać wszystkich wierszy bazy danych w pamięci przed rozpoczęciem zapisywania danych wyjściowych XML - czytasz i piszesz w tym samym czasie. Zajrzyj do nowatorskich silników szablonów lub XSLT, aby strumieniowanie działało w REST.

Z drugiej strony SOAP jest generowany przez usługi generowane przez narzędzia jako duży obiekt blob, a dopiero potem zapisywany. To nie jest absolutna prawda, pamiętajcie, istnieją sposoby na uzyskanie właściwości przesyłania strumieniowego z SOAP, na przykład za pomocą załączników.

Mój proces decyzyjny jest następujący: jeśli chcę, aby konsumenci mogli łatwo obsługiwać moją usługę, a wiadomości, które piszę, będą miały średnią lub małą (10 MB lub mniej) i nie mam nic przeciwko spaleniu dodatkowego procesora cykle na serwerze, idę z SOAP. Jeśli muszę obsługiwać AJAX w przeglądarkach internetowych lub potrzebuję tego, aby przesyłać strumieniowo, lub moje odpowiedzi są gigantyczne, idę na REST.

Wreszcie, wokół SOAP zbudowano wiele świetnych standardów, takich jak WS-Security i uzyskanie stanowych usług sieciowych, do których można się podłączyć, jeśli używasz odpowiednich narzędzi. Tego rodzaju rzeczy naprawdę mają znaczenie i mogą pomóc Ci spełnić niektóre owłosione wymagania.

Wiem, że to stare pytanie, ale muszę opublikować swoją odpowiedź - być może ktoś uzna ją za przydatną. Nie mogę uwierzyć, ile osób poleca REST zamiast SOAP. Mogę tylko założyć, że ci ludzie nie są programistami ani nigdy nie wdrożyli usługi REST o rozsądnej wielkości. Wdrożenie usługi REST zajmuje dużo więcej czasu niż wdrożenie usługi SOAP. I w końcu okazuje się, że jest znacznie bardziej chaotyczny. Oto powody, dla których wybrałem SOAP w 99% przypadków:

1) Wdrożenie usługi REST trwa nieskończenie dłużej niż wdrożenie usługi SOAP. Istnieją narzędzia dla wszystkich współczesnych języków / platform / platform do odczytu w WSDL i wyjściowych klasach proxy i klientach. Wdrożenie usługi REST odbywa się ręcznie i - zdobądź to - czytając dokumentację. Ponadto, wdrażając te dwie usługi, musisz „zgadywać”, co wróci przez potok, ponieważ nie ma prawdziwego schematu ani dokumentu referencyjnego.

2) Po co pisać usługę REST, która i tak zwraca XML? Jedyna różnica polega na tym, że przy REST nie znasz typów, które reprezentuje każdy element / atrybut - możesz sam go wdrożyć i masz nadzieję, że pewnego dnia łańcuch nie napotka pola, o którym myślałeś, że zawsze jest liczbą całkowitą. SOAP definiuje strukturę danych za pomocą WSDL, więc jest to oczywiste.

3) Słyszałem skargę, że dzięki SOAP masz „narzut” na Kopertę SOAP. Czy w dzisiejszych czasach naprawdę musimy martwić się o garść bajtów?

4) Słyszałem argument, że dzięki REST możesz po prostu wstawić adres URL do przeglądarki i zobaczyć dane. Jasne, jeśli twoja usługa REST korzysta z prostego uwierzytelnienia lub nie ma go. Na przykład usługa Netflix korzysta z protokołu OAuth, który wymaga podpisania i zakodowania rzeczy przed wysłaniem żądania.

5) Dlaczego potrzebujemy „czytelnego” adresu URL dla każdego zasobu? Jeśli korzystamy z narzędzia do wdrożenia usługi, czy naprawdę zależy nam na faktycznym adresie URL?

Czy muszę iść dalej?

Większość aplikacji, które piszę, to po stronie serwera C # lub Java, lub aplikacje komputerowe w WinForms lub WPF. Aplikacje te zwykle wymagają bogatszego interfejsu API usługi niż REST. Ponadto nie chcę spędzać więcej niż kilka minut na tworzeniu mojego klienta usługi internetowej. Narzędzia do generowania klientów przetwarzających WSDL pozwalają mi zaimplementować mojego klienta i przejść do zwiększania wartości biznesowej.

Teraz, gdybym pisał usługę internetową jawnie dla niektórych wywołań javascript ajax, prawdopodobnie byłby w REST; tylko ze względu na znajomość technologii klienta i wykorzystanie JSON. Moim zdaniem interfejsy API usług sieciowych używane z javascript prawdopodobnie nie powinny być bardzo złożone, ponieważ ten rodzaj złożoności wydaje się być lepiej obsługiwany po stronie serwera.

Powiedziawszy to, istnieje kilka klientów SOAP dla javascript; Wiem, że jQuery ma jeden. W ten sposób SOAP można wykorzystać z javascript; po prostu nie tak ładnie, jak usługa REST zwracająca ciągi JSON. Więc jeśli miałbym usługę internetową, którą chciałem być wystarczająco złożoną, aby była elastyczna dla dowolnej liczby technologii i zastosowań klienta, wybrałbym SOAP.

Polecam najpierw wybrać REST - jeśli używasz Javy, spójrz na JAX-RS i implementację Jersey . REST jest znacznie prostszy i łatwiejszy do współpracy w wielu językach.

Jak powiedzieli inni w tym wątku, problem z SOAP polega na jego złożoności, gdy pojawiają się inne specyfikacje WS- * i występują niezliczone problemy ze współdziałaniem, jeśli zbłądzisz do niewłaściwych części WSDL, XSD, SOAP, WS-Adresowania itp.

Najlepszym sposobem na ocenę debaty REST v SOAP jest spojrzenie w Internecie - prawie wszyscy duzi gracze w przestrzeni internetowej, google, amazon, ebay, twitter i inni - zwykle używają API RESTful i wolą je od SOAP.

Innym fajnym podejściem do korzystania z REST jest to, że można ponownie wykorzystać wiele kodu i infrastruktury między aplikacją internetową a interfejsem REST. np. renderowanie HTML kontra XML w porównaniu do JSON zasobów jest zwykle dość łatwe dzięki frameworkom takim jak JAX-RS i niejawne widoki - a ponadto jest łatwa do pracy z zasobami RESTful za pomocą przeglądarki internetowej

Jestem pewien, że Don Box stworzył SOAP jako żart - „spójrz, możesz nazwać metody RPC przez Internet”, a dziś jęczy, gdy zdaje sobie sprawę, jak koszmarny koszmar standardów internetowych stał się :-)

REST jest dobry, prosty, wdrożony wszędzie (a więc bardziej „standard” niż standardy) szybko i łatwo. Użyj REST.

Myślę, że oba mają swoje miejsce. W mojej opinii:

SOAP : Lepszy wybór do integracji między starszymi / krytycznymi systemami a systemem sieciowym / usługami sieciowymi, na warstwie podstawowej, gdzie WS- * ma sens (bezpieczeństwo, polityka itp.).

RESTful : Lepszy wybór do integracji między stronami internetowymi, z publicznym API, na GÓRZE warstwy (VIEW, tj. Javascripts odbierające wywołania URI).

Jedną z rzeczy, o których nie wspomniano, jest to, że koperta SOAP może zawierać zarówno nagłówki, jak i części ciała. Pozwala to wykorzystać pełną ekspresję XML do wysyłania i odbierania informacji poza pasmem. O ile mi wiadomo, REST ogranicza Cię do nagłówków HTTP i kodów wyników.

(otoh, czy możesz używać plików cookie z usługą REST, aby wysyłać dane typu „nagłówek” poza pasmem?)

Nie przeocz XML-RPC. Jeśli szukasz lekkiego rozwiązania, wiele można powiedzieć o protokole, który można zdefiniować na kilku stronach tekstu i zaimplementować w minimalnej ilości kodu. XML-RPC istnieje już od lat, ale na jakiś czas wyszedł z mody - ale minimalistyczny urok wydaje się dawać coś w rodzaju odrodzenia w ostatnim czasie.

Odpowiedzi na odświeżone w 2012 r. Pytanie (drugą nagrodą) i przegląd dzisiejszych wyników (inne odpowiedzi).

MYDŁO, plusy i minusy

O SOAP 1.2, zaletach i wadach w porównaniu z „REST” ... Cóż, od 2007 roku możesz opisywać usługi REST Web za pomocą WSDL i używając protokołu SOAP ... To znaczy, jeśli pracujesz trochę ciężej, wszystkie standardy W3C stos protokołów usług WWW może być REST !

To dobry punkt wyjścia, ponieważ możemy sobie wyobrazić scenariusz, w którym tymczasowo unika się wszelkich dyskusji filozoficznych i metodologicznych. Możemy porównać technicznie „SOAP-REST” z „NON-SOAP-REST” w podobnych usługach,

• ODPOWIEDZIALNOŚĆ (= „REST-SOAP”): jak pokazuje L.Mandel , WSDL2 może opisać usługę REST, a jeśli przypuszczamy, że przykładowy kod XML może być zawarty w SOAP, cała implementacja będzie „SOAP-REST” .

• ODPOCZYNEK NA MYDŁO : dowolna usługa internetowa REST, która nie może być SOAP ... To znaczy „90%” dobrze znanych przykładów REST. Niektórzy nie używają XML (np. Typowe REST AJAX używają JSON zamiast tego), inni używają innej struktury XML, bez nagłówków lub reguł SOAP. PS: aby uniknąć nieformalności, możemy założyć REST poziom 2 w porównaniach.

Oczywiście, aby porównać bardziej koncepcyjnie, porównaj „NON-REST-SOAP” z „NON-SOAP-REST”, jako różne podejścia do modelowania. Uzupełniając taksonomię usług sieciowych:

• MYDŁO BEZ ODPOCZYNKU : dowolna usługa internetowa SOAP, która nie może być REST ... To znaczy „90%” dobrze znanych przykładów SOAP.

• NON-REST-NEITHER-SOAP : tak, wszechświat „modelowania usług sieciowych” obejmuje inne rzeczy (np. XML-RPC ).

MYDŁO w warunkach REST

Porównywanie porównywalnych rzeczy: SOAP-REST z NON-SOAP-REST .

PROS

Wyjaśniając niektóre warunki,

• Stabilność umowy : dla wszystkich rodzajów umów (jako „umowy pisemne”),

  • Dzięki zastosowaniu norm : wszystkie poziomy stosu W3C są wzajemnie zgodne. REST, z drugiej strony, nie jest standardem W3C ani ISO i nie zawiera żadnych znormalizowanych szczegółów na temat urządzeń peryferyjnych usługi. Tak więc, jak powiedziałem wcześniej @DaveWoldrich (20 głosów), @cynicalman (5), @Exitos (0), w kontekście, w którym POTRZEBUJESZ STANDARDÓW, potrzebujesz mydła.

  • Dzięki zastosowaniu najlepszych praktyk : „pełny aspekt” implementacji stosu W3C tłumaczy stosowne porozumienia ludzkie / prawne / prawne.

• Solidność : bezpieczeństwo struktury SOAP i nagłówków. Dzięki metadzie komunikacji (z pełną ekspresją XML) i weryfikacji masz „polisę ubezpieczeniową” na wypadek jakichkolwiek zmian lub hałasu.
  SOAP ma „niezawodność transakcyjną (...) zajmującą się awariami komunikacji. SOAP ma więcej kontroli wokół logiki ponownych prób, a tym samym może zapewnić więcej kompleksowych gwarancji niezawodności i usług”, E. Terman .

Sortowanie profesjonalistów według popularności,

• Lepsze narzędzia (~ 70 głosów): SOAP ma obecnie zaletę lepszych narzędzi, od 2007 r. I nadal 2012 r., Ponieważ jest to dobrze zdefiniowany i powszechnie akceptowany standard. Patrz @MarkCidade (27 głosów), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9).

• Zgodność z normami (25 głosów): jak powiedziałem wcześniej , @DaveWoldrich (20 głosów), @cynicalman (5), @Exitos (0), w kontekście, w którym POTRZEBUJESZ STANDARDÓW, potrzebujesz mydła.

• Solidność : ubezpieczenie nagłówków SOAP, @JohnSaunders (8 głosów).

CONS

• Struktura SOAP jest bardziej złożona (ponad 300 głosów): wszystkie odpowiedzi tutaj i źródła o „SOAP vs REST”, wykazują pewien stopień niechęci z redundancją i złożonością SOAP. Jest to naturalna konsekwencja wymagań dotyczących formalnej weryfikacji (patrz poniżej) i solidności (patrz wyżej). „REST NON-SOAP” (i XML-RPC, twórca SOAP ) może być prostszy i nieformalny.

• Ograniczenie „tylko XML” stanowi przeszkodę w wydajności podczas korzystania z małych usług (~ 50 głosów): patrz json.org/xml i to pytanie lub to drugie . Wskazuje na to @toluju (41) i inni.
  PS: ponieważ JSON nie jest standardem IETF , ale możemy uznać go za standard dla społeczności oprogramowania sieciowego.

Usługi modelowania za pomocą SOAP

Teraz możemy dodać SOAP-NON-REST z porównaniami NON-SOAP-REST i wyjaśnić, kiedy lepiej jest używać SOAP :

• Potrzeba standardów i stabilnych umów (patrz sekcja „PROS”). PS: zobacz typową „potrzebę B2B dotyczącą standardów” opisaną przez @saille .

• Potrzebujesz narzędzi (patrz sekcja „PROS”). PS: Standardy i istnienie weryfikacji formalnej (patrz poniżej), to ważne kwestie dla automatyzacji narzędzia.

• Równoległe ciężkie przetwarzanie (patrz sekcja „Kontekst / podstawy” poniżej): przy większych i / lub wolniejszych procesach, bez względu na nieco większą złożoność SOAP, niezawodność i stabilność są najlepszymi inwestycjami.

• Potrzebujesz większego bezpieczeństwa : gdy wymagany jest więcej niż HTTPS i naprawdę potrzebujesz dodatkowych funkcji do ochrony, SOAP jest lepszym wyborem ( patrz @Bell , 32 głosy). „Wysłanie wiadomości ścieżką bardziej skomplikowaną niż żądanie / odpowiedź lub transport, który nie wymaga HTTP”, S. Seely . XML jest kluczową kwestią, oferując standardy XML Encryption , XML Signature i XML kanonizacją , a jedynie z mydłem można osadzić te mechanizmy do wiadomości przez dobrze przyjętym standardem jak WS-Security .

• Potrzebujesz większej elastyczności (mniej ograniczeń): SOAP nie potrzebuje dokładnej korespondencji z URI; nie wymaga ograniczenia do HTTP; nie trzeba ograniczać się do 4 czasowników. Jak mówi @TravisHeseman (9 głosów), jeśli chcesz czegoś „elastycznego dla dowolnej liczby technologii i zastosowań klienta”, użyj SOAP.
  PS: pamiętaj, że XML jest bardziej uniwersalny / ekspresyjny niż JSON (i in.).

• Potrzeba formalnych weryfikacji : ważne, aby zrozumieć, że stos W3C korzysta z metod formalnych , a REST jest bardziej nieformalny. Opis usługi WSDL ( język formalny ) jest formalną specyfikacją interfejsów usług sieciowych, a SOAP to solidny protokół, który akceptuje wszystkie możliwe recepty WSDL.

KONTEKST

Historyczny

Aby ocenić trendy, konieczna jest perspektywa historyczna. W tym temacie perspektywa 10 lub 15 lat ...

Przed standaryzacją W3C istnieje pewna anarchia. Trudno było wdrożyć interoperacyjne usługi z różnymi strukturami, a trudniej, kosztowniej i czasochłonnie wdrożyć coś interoperacyjnego między firmami. Standardy stosu W3C to lekka, północna do współpracy zestawów złożonych usług internetowych.

W przypadku codziennych zadań, takich jak wdrażanie AJAX, SOAP jest ciężkie ... Tak więc potrzeba prostych rozwiązań wymaga wyboru nowej struktury teorii ... I dużych „odtwarzaczy oprogramowania sieciowego”, takich jak Google, Amazon, Yahoo i wsp. Wybrali najlepszą alternatywę, czyli podejście REST. Czy w tym kontekście koncepcja REST pojawiła się jako „konkurencyjne środowisko”, a dziś (2012 r.) Ta alternatywa jest de facto standardem dla programistów.

Podwaliny

W kontekście przetwarzania równoległego usługi sieciowe udostępniają podzadania równoległe; a protokoły, takie jak SOAP, zapewniają dobrą synchronizację i komunikację. Nie „jakiekolwiek zadanie”: usługi sieciowe można zaklasyfikować jako
gruboziarniste i krępujące paralelizm .

W miarę jak zadanie staje się coraz większe, staje się ono mniej znaczącą „debatą na temat złożoności”, a bardziej istotne staje się solidność komunikacji i solidność umów.

Jest dopracowany.

Jeśli potrzebujesz mieć interfejs innych systemów z twoimi usługami, wielu klientów będzie zadowolonych z SOAP, z powodu warstw „weryfikacji”, którą masz z umowami, WSDL i standardem SOAP.

W przypadku codziennych systemów wywołujących systemy, myślę, że SOAP to dużo niepotrzebnych kosztów ogólnych, gdy wystarczy proste wywołanie HTML.

Patrzę na to samo i myślę, że są to różne narzędzia do różnych problemów .

Simple Object Access Protocol (SOAP), język XML definiujący architekturę komunikatów i formaty komunikatów, jest używany przez usługi sieciowe i zawiera opis operacji. WSDL jest językiem opartym na XML do opisywania usług internetowych i uzyskiwania do nich dostępu. będzie działał na SMTP, HTTP, FTP itp. Wymaga wsparcia oprogramowania pośredniego, dobrze zdefiniowanego mechanisamu do zdefiniowania usług takich jak WSDL + XSD, WS-Policy SOAP zwróci dane oparte na XML SOAP zapewnia standardy bezpieczeństwa i niezawodności

Usługi sieci Web reprezentatywnego transferu stanu (RESTful). są to usługi sieciowe drugiej generacji. Usługi sieciowe RESTful, komunikują się za pośrednictwem protokołu HTTP niż usługi oparte na SOAP i nie wymagają komunikatów XML ani definicji interfejsu API usługi WSDL. dla REST nie jest wymagane oprogramowanie pośrednie, wymagana jest tylko obsługa HTTP. WADL Standard, REST może zwracać XML, zwykły tekst, JSON, HTML itp.

Wielu typom klientów łatwiej jest korzystać z usług sieciowych RESTful, umożliwiając jednocześnie ewolucję i skalowanie strony serwera. Klienci mogą korzystać z niektórych lub wszystkich aspektów usługi i łączyć ją z innymi usługami internetowymi.

1. REST korzysta ze standardowego protokołu HTTP, dlatego łatwiej jest tworzyć klientów i tworzyć interfejsy API
2. REST zezwala na wiele różnych formatów danych, takich jak XML, zwykły tekst, JSON, HTML, gdzie jako SOAP zezwala tylko na XML.
3. REST ma lepszą wydajność i skalowalność.
4. Odpocznij i może być buforowany, a SOAP nie
5. Wbudowana obsługa błędów w przypadku SOAP Brak obsługi błędów
6. REST jest szczególnie przydatnym urządzeniem PDA i innymi urządzeniami mobilnymi.

Usługi REST są łatwe do zintegrowania z istniejącymi stronami internetowymi.

SOAP ma zestaw protokołów, które zapewniają standardy bezpieczeństwa i niezawodności, między innymi, i współpracują z innymi klientami i serwerami zgodnymi z WS. Usługi sieciowe SOAP (takie jak JAX-WS) są przydatne w obsłudze przetwarzania asynchronicznego i wywoływania.

W przypadku złożonego API SOAP będzie bardziej użyteczny.

REST jest architekturą wymyśloną przez Roya Fieldinga i opisaną w rozprawie „ Style architektoniczne i projektowanie architektur oprogramowania sieciowego” . Roy jest także głównym autorem HTTP - protokołu, który definiuje przesyłanie dokumentów przez Internet. HTTP jest protokołem RESTful. Gdy programiści mówią o „korzystaniu z usług REST Web”, prawdopodobnie bardziej trafne jest powiedzenie „za pomocą HTTP”.

SOAP to protokół oparty na XML, który tuneluje wewnątrz żądania / odpowiedzi HTTP, więc nawet jeśli używasz SOAP, również używasz REST. Trwa debata na temat tego, czy SOAP dodaje znaczącą funkcjonalność do podstawowego HTTP.

Przed napisaniem usługi sieciowej zaleciłbym studiowanie HTTP. Szanse są twoje wymagania mogą być zaimplementowane z funkcjonalnością już zdefiniowaną w specyfikacji, więc inne protokoły nie będą potrzebne.

Patrzę na ten sam problem. Wydaje mi się, że tak naprawdę REST jest szybki, łatwy i dobry dla lekkich połączeń i odpowiedzi oraz świetny do debugowania (co może być lepszego niż wpompowanie adresu URL do przeglądarki i zobaczenie odpowiedzi).

Jednak, gdy REST wydaje się upaść, wiąże się to z faktem, że nie jest to standard (chociaż składa się ze standardów). Większość bibliotek programistycznych ma sposób na sprawdzenie WSDL w celu automatycznego wygenerowania kodu klienta potrzebnego do korzystania z usług opartych na SOAP. Dotychczasowe usługi sieciowe oparte na REST wydają się bardziej doraźnym podejściem do pisania interfejsu w celu dopasowania możliwych połączeń. Wykonanie ręcznego żądania HTTP, a następnie parsowanie odpowiedzi. To samo w sobie może być niebezpieczne.

Zaletą SOAP jest to, że po wydaniu WSDL biznes może „ustrukturyzować swoją logikę aorund, która ustawi kontrakt, każda zmiana interfejsu zmieni wsdl. Nie ma miejsca na manewr. Możesz zweryfikować wszystkie żądania względem tego WSDL. Ponieważ jednak WSDL nie opisuje poprawnie usługi REST, nie ma określonego sposobu uzgodnienia interfejsu do komunikacji.

Z perspektywy biznesowej wydaje się, że pozostawia to komunikację otwartą na interpretację i zmiany, co wydaje się złym pomysłem.

Górne „Odpowiedź” w tym wątku wydaje się mówić, że SOAP oznacza Simple Object -oriented Protocol, jednak patrząc na wiki, O oznacza Object nie Object -oriented. To są różne rzeczy.

Wiem, że ten post jest bardzo stary, ale pomyślałem, że powinienem odpowiedzieć własnymi ustaleniami.

To dobre pytanie ... Nie chcę cię zwieść, więc jestem otwarty na odpowiedzi innych ludzi tak samo jak ty. Dla mnie tak naprawdę sprowadza się to do kosztów ogólnych i do czego służy API. Wolę konsumować usługi sieciowe podczas tworzenia oprogramowania klienckiego, ale nie podoba mi się waga SOAP. Uważam, że REST jest lżejszy, ale nie lubię z nim pracować z perspektywy klienta prawie tak samo.

Jestem ciekawy, co myślą inni.

Posłuchaj tego podcastu, aby się dowiedzieć. Jeśli chcesz poznać odpowiedź bez słuchania, to OK, to REST. Ale naprawdę polecam słuchanie.

Zasadą ogólną jest to, że jeśli chcesz, aby klient WWW przeglądarki łączył się bezpośrednio z usługą, prawdopodobnie powinieneś użyć REST. Jeśli chcesz przekazywać dane strukturalne między usługami zaplecza, użyj SOAP.

Skonfigurowanie protokołu SOAP może być czasem bardzo uciążliwe i często stanowi przesadę w przypadku prostej wymiany danych klienta i serwera. Niestety, najprostsze przykłady programowania, które widziałem (i których się nauczyłem) nieco wzmacniają to postrzeganie.

To powiedziawszy, SOAP naprawdę błyszczy, gdy zaczniesz łączyć wiele usług SOAP razem w ramach większego procesu napędzanego przepływem danych (pomyśl oprogramowanie korporacyjne). Jest to coś, czego wiele przykładów programowania SOAP nie przekazuje, ponieważ prosta operacja SOAP polegająca na zrobieniu czegoś, na przykład pobrania ceny akcji, jest na ogół nadmiernie skomplikowana w stosunku do tego, co robi sama, chyba że jest przedstawiona w kontekście udostępnienia maszyny czytelny interfejs API wyszczególniający określone funkcje z ustawionymi formatami danych dla wejść i wyjść, który z kolei jest skryptowany przez większy proces.

Jest to poniekąd smutne, ponieważ naprawdę daje SOAP złą reputację, ponieważ trudno jest wykazać zalety SOAP bez przedstawienia go w pełnym kontekście użycia produktu końcowego.

SOAP ucieleśnia podejście do usług sieciowych zorientowane na usługi - takie, w którym metody (lub czasowniki) są podstawowym sposobem interakcji z usługą. REST przyjmuje podejście zorientowane na zasoby, w którym obiekt (lub rzeczownik) zajmuje centralne miejsce.

W sensie „PHP-universe” wsparcie PHP dla każdego zaawansowanego SOAP jest do bani. Skończysz używać czegoś takiego jak http://wso2.com/products/web-services-framework/php/, gdy tylko przekroczysz podstawowe potrzeby, nawet aby włączyć WS-Security lub WS-RM bez wbudowanej obsługi.

Wydaje mi się, że tworzenie obwiedni SOAP w PHP jest bardzo nieporządne, ponieważ tworzy przestrzenie nazw, xsd: nil, xsd: anytype i usługi mydła w starym stylu, które używają kodowania SOAP (Bóg wie, jak to inaczej) w komunikatach SOAP.

Unikaj całego tego bałaganu, pozostając przy REST, REST to nic naprawdę wielkiego, z którego korzystamy od początku WWW. Uświadomiliśmy sobie, że kiedy ukazał się ten http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm artykuł, pokazuje, w jaki sposób możemy wykorzystać możliwości HTTP do wdrożenia usług RESTFul. HTTP jest z natury REST, co nie znaczy, że użycie HTTP powoduje, że twoje usługi RESTFul.

SOAP zaniedbuje podstawowe możliwości HTTP i traktuje HTTP jako protokół transportowy, dlatego jest teoretycznie niezależny od protokołu transportowego (w praktyce nie jest tak, że słyszałeś o nagłówku Action SOAP? Jeśli nie google teraz!).

Wraz ze wzrostem adaptacji JSON i HTML5 z dojrzewaniem javascript REST z JSON stał się najpopularniejszym sposobem radzenia sobie z usługami. Schemat JSON został również zdefiniowany i może być używany do rozwiązań na poziomie przedsiębiorstwa (wciąż na wczesnych etapach) wraz z WADL, jeśli to konieczne.

Obsługa PHP REST i JSON jest zdecydowanie lepsza niż istniejące wbudowane wsparcie SOAP.

Dodając jeszcze kilka słów BUZZ tutaj SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

tak na marginesie, uwielbiam SOAP, szczególnie dla specyfikacji WS-Security, jest to jedna dobra specyfikacja i jeśli ktoś myślący w adaptacji Enterprise JSON na pewno potrzebuje czegoś podobnego do JSON, takiego jak szyfrowanie na poziomie pola itp.

Jeden szybki punkt - protokół transmisji i aranżacja;

Używam SOAP przez TCP ze względów szybkości, niezawodności i bezpieczeństwa, w tym zaaranżowanych usług maszyna-maszyna (ESB) i usług zewnętrznych. Zmień definicję usługi, koordynacja wywołuje błąd ze zmiany WSDL i jest natychmiast oczywista i może zostać odbudowana / wdrożona.

Nie jestem pewien, czy możesz zrobić to samo z REST - czekam na korektę lub oczywiście! Za pomocą REST zmień definicję usługi - nic o niej nie wie, dopóki nie zwróci 400 (lub cokolwiek innego).

Jeśli szukasz interoperacyjności między różnymi systemami i językami, zdecydowanie wybrałbym REST. Na przykład miałem wiele problemów z próbą uruchomienia SOAP między .NET a Javą.

tworzę punkt odniesienia, aby dowiedzieć się, które z nich są szybsze! widzę ten wynik:

na 1000 wniosków:

• REST trwał 3 sekundy
• SOAP zajęło 7 sekund

dla 10 000 wniosków:

• REST trwał 33 sekundy
• SOAP zajęło 69 sekund

dla 1 000 000 wniosków:

• REST zajął 62 sekundy
• SOAP zajęło 114 sekund

Stare pytanie, ale wciąż aktualne dzisiaj ... z powodu tak wielu programistów w przestrzeni korporacyjnej, którzy wciąż go używają.

Moja praca polega na projektowaniu i rozwijaniu rozwiązań Internetu Rzeczy (Internet of Things). Obejmuje to opracowanie kodu dla małych urządzeń osadzonych komunikujących się z chmurą.

Oczywiste jest, że usługa REST jest obecnie powszechnie akceptowana i przydatna, i jest niemal standardem defacto dla sieci, nawet Microsoft ma obsługę REST zawartą na platformie Azure. Gdybym musiał polegać na SOAP, nie mógłbym zrobić tego, co muszę, ponieważ jest to po prostu zbyt duży, nieporęczny i irytujący dla małych urządzeń osadzonych.

REST jest prosty, czysty i mały. Dzięki temu jest idealny dla małych urządzeń wbudowanych. Zawsze krzyczę, gdy współpracuję z programistą internetowym, który wysyła mi WSDL. Będę musiał rozpocząć kampanię edukacyjną o tym, dlaczego to po prostu nie zadziała i dlaczego będą musieli się uczyć REST.

1. Z mojego doświadczenia. Powiedziałbym, że REST daje ci dostęp do adresu URL, który jest już zbudowany. np.> wyszukiwanie słów w google. Ten adres URL może służyć jako usługa internetowa dla usługi REST. W SOAP możesz utworzyć własną usługę internetową i uzyskać do niej dostęp za pośrednictwem klienta SOAP.

2. REST obsługuje format tekstowy, JSON, XML. Dlatego bardziej wszechstronny do komunikacji między dwiema aplikacjami. Podczas gdy SOAP obsługuje tylko format XML do komunikacji wiadomości.