Dlaczego miałoby się używać REST zamiast usług opartych na SOAP? [Zamknięte]

Uczestniczyłem dzisiaj w interesującej demonstracji na REST, jednak nie mogłem wymyślić ani jednego powodu (ani nie został on przedstawiony), dla którego REST jest w każdym razie lepszy lub prostszy w użyciu i implementacji niż stos usług oparty na SOAP.

Jakie są niektóre z powodów, dlaczego ktokolwiek w „prawdziwym świecie” używa REST zamiast usług opartych na SOAP?

Mniejszy narzut (brak koperty SOAP do zawijania każdego połączenia)

Mniej duplikacji (HTTP już reprezentuje operacje takie jak DELETE, PUT, GET itp., Które w innym przypadku muszą być reprezentowane w kopercie SOAP).

Bardziej ustandaryzowane - operacje HTTP są dobrze zrozumiane i działają konsekwentnie. Niektóre implementacje SOAP mogą być skomplikowane.

Bardziej czytelny dla człowieka i testowalny (trudniejszy do przetestowania SOAP za pomocą samej przeglądarki).

Nie musisz używać XML (cóż, nie musisz też tego robić w przypadku SOAP, ale nie ma to sensu, ponieważ już robisz parsowanie koperty).

Biblioteki uczyniły SOAP (w pewnym sensie) łatwym. Ale jak zauważyłem, usuwasz wiele zbędnych elementów. tak w teorii, SOAP może przejść przez inne transporty, aby uniknąć jazdy po warstwie i robienia podobnych rzeczy, ale w rzeczywistości prawie cała praca SOAP, jaką kiedykolwiek wykonasz, odbywa się przez HTTP.

Usługi RESTful są znacznie prostsze w użyciu niż (zwykłe) usługi oparte na SOAP . Powodem tego jest fakt, że REST jest oparty na zwykłych żądaniach HTTP, co umożliwia wywnioskowanie intencji na podstawie typu żądania (GET = retrive, POST = write, DELETE = remove, itd.) I jest całkowicie bezstanowy. Z drugiej strony można argumentować, że jest mniej elastyczny, ponieważ eliminuje koncepcję koperty wiadomości zawierającej kontekst żądania.

Z mojego doświadczenia wynika, że ​​SOAP był preferowany dla usług w przedsiębiorstwie, a REST był preferowany dla usług, które są udostępniane jako publiczne interfejsy API.

Dzięki narzędziom takim jak WCF w środowisku .NET implementacja usługi jako REST lub SOAP jest bardzo prosta.

Kilka istotnych lektur:

• Blog Amazon Web Services: REST vs SOAP
• Dare Obasanjo często pisze o REST

Zakładam, że kiedy mówisz „usługi sieciowe”, masz na myśli SOAP i zestaw standardów WS- *. (W przeciwnym razie mógłbym argumentować, że usługi REST to „usługi sieciowe”).

Kanonicznym argumentem jest to, że usługi REST są bliższe projektowi sieci - to znaczy projektowi protokołu HTTP i powiązanej infrastruktury. Dzięki temu korzystanie z usługi REST będzie bardziej zgodne z istniejącymi narzędziami i technikami internetowymi.

Oczywiście, gdy zagłębisz się w szczegóły, okaże się, że oba podejścia mają mocne strony w różnych scenariuszach. Czy interesują Cię te szczegóły?

Narzut nie jest tak ważny jak dobra architektura.

REST nie jest protokołem, to architektura, która zachęca do dobrego, skalowalnego projektowania. Jest często wybierany, ponieważ zbyt duża swoboda w RPC może łatwo doprowadzić do złego projektu.

Drugim powodem jest przewidywalny koszt protokołów RESTful przez HTTP, ponieważ może on wykorzystywać istniejące technologie (głównie proxy). Początkowy koszt RPC jest dość niski, ale ma tendencję do znacznego wzrostu wraz ze wzrostem obciążenia.

REST jest niezależny od implementacji i znacznie bardziej przejrzysty, co czyni go doskonałym dla publicznych interfejsów API, zwłaszcza dla dużych witryn internetowych, takich jak Flickr, Amazon lub Digg, które używają swoich interfejsów API jako narzędzi marketingowych i naprawdę chcą, aby ludzie korzystali z ich danych. Oni nie chcą być ręcznie gospodarstwa 1000s początkujących programistów, którzy próbują zdiagnozować języka skryptowego buggy biblioteki SOAP za wybór.

W przeciwieństwie do SOAP i WSDL, które są lepsze dla aplikacji wewnętrznych, w których masz biblioteki typu drop-in i znanych, niewyraźnych ludzi na obu końcach. (I być może nie musisz przejmować się takimi rzeczami, jak równoważenie obciążenia w skali Internetu, buforowanie HTTP itp.) Następnie otrzymujesz interfejsy API, które są samodokumentowane, zachowują typy itp. Przy zerowej pracy.

Muszę przeczytać najlepszą rozprawę Roya Fieldinga na ten temat. On sprawia, że doskonały przypadek i był zdecydowanie WAY wyprzedzał swoje czasy, kiedy pisał go (2000).

Warto przeczytać blog Steve'a Vinoskiego i jego najnowsze artykuły . To były guru CORBA, który wraz z Michi Henning napisał prawdopodobnie najlepszą książkę na ten temat „Advanced CORBA® Programming with C ++” . Jednak od tamtej pory widział błąd w swoich sposobach klient / serwer, a teraz przysięga na REST.

REST umożliwia buforowanie operacji niemutujących (które zazwyczaj używają czasownika GET) . To znaczy buforowane przez klienta i / lub buforowane przez serwery proxy. To może być ogromna wygrana!

REST to po prostu sposób implementacji usług internetowych. Jest to tylko sposób na poprawne użycie protokołu HTTP do wysyłania zapytań do usług internetowych, które próbujesz uzyskać.

http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer

Jest super prosty i smukły. Możesz to zrobić za pomocą przeglądarki, używając czasownika http: GET. Nie znalazłem przeglądarki, która może łatwo ręcznie wykonać ogólne żądanie HTTP POST

Oto jeden punkt danych: Amazon oferuje swoje interfejsy API zarówno w formatach REST, jak i SOAP, a 85% wykorzystania to REST.

REST jest łatwiejszy do wdrożenia, łatwiejszy do zrozumienia i zapewnia wyższą wydajność.