Czy usługa internetowa w stylu Netflix lub Twittera powinna używać REST lub SOAP? [Zamknięte]

Zaimplementowałem dwie usługi REST: Twitter i Netflix. Za każdym razem starałem się znaleźć zastosowanie i logikę związaną z decyzją o udostępnieniu tych usług jako REST zamiast SOAP. Mam nadzieję, że ktoś może mnie wskazać, czego mi brakuje i wyjaśnić, dlaczego REST został użyty jako implementacja usługi dla usług takich jak te.

1. Implementacja usługi REST trwa nieskończenie dłużej niż implementacja usługi SOAP. Istnieją narzędzia dla wszystkich nowoczesnych języków / frameworków / platform do odczytywania w WSDL i wyprowadzania klas proxy i klientów. Wdrożenie usługi REST odbywa się ręcznie i - zdobądź to - czytając dokumentację. Co więcej, podczas implementacji tych dwóch usług, musisz „zgadywać”, co się powtórzy, ponieważ nie ma prawdziwego schematu ani dokumentu referencyjnego.

2. Po co i tak pisać usługę REST, która zwraca XML? Jedyną różnicą jest to, że w przypadku REST nie znasz typów, które reprezentuje każdy element / atrybut - jesteś sam, aby go zaimplementować i masz nadzieję, że pewnego dnia łańcuch nie pojawi się w polu, o którym myślałeś, że zawsze jest int. SOAP definiuje strukturę danych za pomocą WSDL, więc jest to oczywiste.

3. Słyszałem narzekanie, że w przypadku SOAP masz „narzut” koperty SOAP. Czy w dzisiejszych czasach naprawdę musimy się martwić o garść bajtów?

4. Słyszałem argument, że dzięki REST możesz po prostu wrzucić adres URL do przeglądarki i zobaczyć dane. Jasne, jeśli Twoja usługa REST korzysta z prostego uwierzytelniania lub bez niego. Na przykład usługa Netflix korzysta z protokołu OAuth, który wymaga podpisywania i kodowania rzeczy, zanim będziesz mógł przesłać żądanie.

5. Dlaczego potrzebujemy „czytelnego” adresu URL dla każdego zasobu? Gdybyśmy używali narzędzia do realizacji usługi, czy naprawdę zależy nam na rzeczywistym adresie URL?

Kanarek w kopalni węgla.

Na takie pytanie czekałem blisko rok. To było nieuniknione, że ten dzień nadejdzie i jestem pewien, że takich pytań zobaczymy o wiele więcej w nadchodzących miesiącach.

Znaki ostrzegawcze

Masz całkowitą rację, budowanie klientów RESTful trwa dłużej niż klientów SOAP. Zestawy narzędzi SOAP zabierają dużo standardowego kodu i sprawiają, że obiekty proxy klienta są dostępne prawie bez wysiłku. Za pomocą narzędzia takiego jak Visual Studio i adres URL serwera mogę uzyskać dostęp do zdalnych obiektów o dowolnej złożoności lokalnie w mniej niż pięć minut.

Usługi, które zwracają application / xml i application / json są bardzo denerwujące dla programistów-klientów. Co mamy zrobić z tą plamą danych?

Na szczęście wiele witryn oferujących usługi REST udostępnia również kilka bibliotek klienckich, dzięki czemu możemy użyć tych bibliotek, aby uzyskać dostęp do wielu obiektów o jednoznacznie określonym typie. Choć wydaje się to trochę głupie. Gdyby używali SOAP, moglibyśmy sami wygenerować kod dla tych klas proxy.

Narzut mydła, ha. To opóźnienie zabija. Jeśli ludzie są naprawdę zaniepokojeni liczbą nadmiarowych bajtów przesyłanych przez sieć, być może HTTP nie jest właściwym wyborem. Czy widziałeś, ile bajtów jest używanych przez nagłówek klienta użytkownika?

Tak, czy kiedykolwiek próbowałeś używać przeglądarki internetowej jako narzędzia do debugowania czegokolwiek innego niż HTML i JavaScript. Zaufaj mi, to jest do bani. Możesz użyć tylko dwóch czasowników, buforowanie ciągle przeszkadza, obsługa błędów pochłania tyle informacji, że ciągle szuka cholernego favicon.ico. Po prostu mnie zastrzel.

Czytelny adres URL. Tylko rzeczowniki, bez czasowników. Tak, to proste, o ile wykonujemy tylko operacje CRUD i musimy uzyskać dostęp do hierarchii obiektów tylko w jeden sposób. Niestety większość aplikacji wymaga nieco większej funkcjonalności.

Zbliżająca się katastrofa

Istnieje pewna liczba programistów, którzy obecnie opracowują aplikacje integrujące się z usługami REST, którzy dochodzą do tego samego zestawu wniosków, co Ty. Obiecano im prostotę, elastyczność, skalowalność, możliwość rozwoju i święty Graal nieoczekiwanego ponownego wykorzystania. Charakterystyka samej sieci, jak coś może pójść nie tak.

Jednak odkrywają, że przechowywanie wersji jest równie dużym problemem, ale kompilator nie pomaga w wykrywaniu problemów. Odręczny kod klienta jest trudny w utrzymaniu, ponieważ struktury danych ewoluują, a adresy URL są refaktoryzowane. Projektowanie interfejsów API w oparciu o same rzeczowniki i cztery czasowniki może być naprawdę trudne, zwłaszcza gdy zeloty RESTful Url mówią ci, kiedy możesz, a kiedy nie możesz używać ciągów zapytań.

Programiści zaczną pytać, dlaczego marnujemy wysiłek na obsługę zarówno formatów Json, jak i formatów Xml, dlaczego nie skupić się tylko na jednym i zrobić to dobrze?

Jak poszło tak źle

Powiem ci, co poszło nie tak. Jako programiści pozwalamy działom marketingu wykorzystać naszą główną słabość. Nasze wieczne poszukiwania srebrnej kuli zaślepiły nas na rzeczywistość tego, czym naprawdę jest REST. Z pozoru REST wydaje się taki łatwy i prosty. Nazwij swoje zasoby za pomocą adresów URL i użyj funkcji GET, PUT, POST i DELETE. Do diabła, my, programiści, już wiemy, jak to zrobić, od lat mamy do czynienia z bazami danych, które mają tabele i kolumny oraz instrukcje SQL, które mają SELECT, INSERT, UPDATE i DELETE. To powinien być kawałek ciasta.

Istnieją inne części REST, które niektórzy omawiają, takie jak samoopisywanie i ograniczenie hipermedialne, ale te ograniczenia nie są tak proste, jak identyfikacja zasobów i jednolity interfejs. Wydaje się, że dodają złożoności, gdzie pożądanym celem jest prostota.

Ta rozwodniona wersja REST została sprawdzona w kulturze programistów na wiele sposobów. Stworzono struktury serwerowe, które zachęcały do ​​identyfikacji zasobów i jednolitego interfejsu, ale nie wspierały innych ograniczeń. Pojęcia zaczęły krążyć wokół różnicując podejścia (HI-REST vs LO-REST, Corporate REST vs Academic REST, REST vs RESTful).

Kilka osób krzyczy, że jeśli nie zastosujesz wszystkich ograniczeń, to nie jest to REST. Nie uzyskasz korzyści. Nie ma połowy REST. Ale te głosy zostały nazwane religijnymi fanatykami, którzy byli zdenerwowani, że ich cenny termin został wykradziony z zapomnienia i wprowadzony do głównego nurtu. Zazdrośni ludzie, którzy starają się, aby REST brzmiał trudniej niż jest.

Termin REST zdecydowanie stał się głównym nurtem. Prawie każda większa usługa internetowa z interfejsem API obsługuje „REST”. Twitter i Netflix to dwa bardzo znane. Przerażające jest to, że mogę pomyśleć tylko o jednym publicznym API, które jest samoopisowe, i jest kilka, które naprawdę implementują ograniczenie hipermedialne. Z pewnością niektóre witryny, takie jak StackOverflow i Gowalla, obsługują linki w swoich odpowiedziach, ale w ich linkach są ogromne luki. Interfejs API StackOverflow nie ma strony głównej. Wyobraź sobie, jak skuteczna byłaby witryna internetowa, gdyby nie było jej strony głównej!

Obawiam się, że zostałeś wprowadzony w błąd

Jeśli dotarłeś tak daleko, krótką odpowiedzią na twoje pytanie jest to, że te interfejsy API (Netflix i Twitter) nie spełniają wszystkich ograniczeń i dlatego nie uzyskasz korzyści, jakie mają przynosić REST api.

Budowanie klientów REST trwa dłużej niż klientów SOAP, ale nie są one powiązane z jedną konkretną usługą, więc powinno być możliwe ich ponowne użycie w różnych usługach. Weźmy klasyczny przykład przeglądarki internetowej. Do ilu usług może uzyskać dostęp przeglądarka internetowa? A co z czytnikiem kanałów? Teraz do ilu różnych usług może uzyskać dostęp przeciętny klient Twittera? Tak, tylko jeden.

Klientów REST nie należy budować w taki sposób, aby łączyły się z pojedynczą usługą, należy ich budować, aby obsługiwały określone typy mediów, które mogą być obsługiwane przez dowolną usługę. Oczywiste pytanie brzmi: w jaki sposób można zbudować klienta REST dla usługi, która dostarcza application / json lub application / xml. Cóż, nie możesz. Dzieje się tak, ponieważ te formaty są całkowicie bezużyteczne dla klienta REST. Sam to powiedziałeś

musisz "zgadywać" co wróci do potoku, ponieważ nie ma prawdziwego schematu ani dokumentu referencyjnego

Masz absolutną rację w przypadku usług takich jak Twitter. Jednak samoopisowe ograniczenie w REST mówi, że nagłówek typu zawartości HTTP powinien dokładnie opisywać zawartość, która jest przesyłana przez sieć. Dostarczenie application / json i application / xml nie mówi nic o zawartości.

Jeśli chodzi o wydajność systemów opartych na REST, należy spojrzeć z szerszej perspektywy. Mówienie o bajtach obwiedni jest jak mówienie o rozwijaniu pętli podczas porównywania sortowania szybkiego z sortowaniem w powłoce. Istnieją scenariusze, w których SOAP może działać lepiej, i są scenariusze, w których REST może działać lepiej. Kontekst jest wszystkim.

REST zyskuje znaczną część swojej przewagi w zakresie wydajności, będąc bardzo elastycznym w zakresie obsługiwanych typów nośników oraz dzięki zaawansowanej obsłudze buforowania. Aby buforowanie działało dobrze, należy przestrzegać prawie wszystkich ograniczeń.

Twoja ostatnia uwaga dotycząca czytelnych adresów URL jest zdecydowanie najbardziej ironiczna. Jeśli naprawdę zastosujesz się do ograniczenia hipermediów, każdy adres URL może być identyfikatorem GUID, a programista klienta nie straci nic na czytelności.

Fakt, że identyfikatory URI powinny być nieprzejrzyste dla klienta, jest jedną z najważniejszych rzeczy podczas tworzenia systemów REST. Czytelne adresy URL są wygodne dla programistów serwera, a dobrze zorganizowane adresy URL ułatwiają strukturze serwera wysyłanie żądań, ale są to szczegóły implementacji, które nie powinny mieć wpływu na programistów korzystających z interfejsu API.

Twitter API nie jest nawet bliski bycia RESTful i dlatego nie widzisz żadnych korzyści z używania go przez SOAP. Interfejs API Netflix jest znacznie bliżej, ale użycie ogólnych typów mediów pokazuje, że nieprzestrzeganie nawet jednego ograniczenia może mieć głęboki wpływ na korzyści płynące z usługi.

Może to nie wszystko ich wina

Zrobiłem dużo dumpingu na usługodawcach, ale potrzeba dwóch, aby tańczyć RESTfully. Usługa może przestrzegać wszystkich ograniczeń religijnie, a klient nadal może łatwo cofnąć wszystkie korzyści.

Jeśli klient na stałe koduje adresy URL, aby uzyskać dostęp do określonych typów zasobów, uniemożliwia to serwerowi zmianę tych adresów URL. Wszelkie konstrukcje adresów URL oparte na niejawnej wiedzy na temat struktury adresów URL przez usługę stanowią naruszenie.

Przyjmowanie założeń dotyczących tego, jaki typ reprezentacji zostanie zwrócony z łącza, może prowadzić do problemów. Przyjmowanie założeń dotyczących zawartości reprezentacji w oparciu o wiedzę, która nie jest wyraźnie określona w nagłówkach HTTP, z pewnością stworzy sprzężenie, które spowoduje ból w przyszłości.

Czy powinni użyć SOAP?

Osobiście nie sądzę. REST wykonany prawidłowo pozwala systemowi rozproszonemu ewoluować w perspektywie długoterminowej. Jeśli budujesz systemy rozproszone, które mają komponenty opracowane przez różnych ludzi i muszą działać przez wiele lat, REST jest całkiem dobrą opcją.

SOAP jest zorientowany obiektowo , Remote Procedure Call technologia stos. Działa poprzez budowanie nowej abstrakcji na podstawie istniejącego protokołu (HTTP).

REST to podejście zorientowane na dokumenty , które po prostu wykorzystuje funkcje istniejącego protokołu (HTTP). „REST” to tylko modne hasło - koncepcja jest taka: po prostu korzystaj z sieci w sposób, w jaki została zaprojektowana !

W odpowiedzi na zmiany pytania:

1. „Implementacja usługi REST trwa nieskończenie dłużej niż implementacja usługi SOAP”.

   Nie, to nie może trwać nieskończenie dłużej. A w przypadkach, gdy to, co próbujesz odzyskać, jest już dokumentem lub plikiem , w rzeczywistości jest to znacznie szybsze . Na przykład specyfikacja OGC dla WMS (Web Mapping Service) definiuje zarówno wersję protokołu SOAP, jak i REST, i jest powód, dla którego prawie nikt nie implementuje wersji SOAP - to dlatego, że jeśli próbujesz uzyskać mapę, jest to o wiele łatwiej jest po prostu zbudować adres URL i pobrać bajty obrazu z tego adresu, niż zawracać sobie głowę umieszczaniem go w wiadomości SOAP. Ale tak, zgodzę się, że jeśli celem usługi sieciowej jest przeniesienie jakiegoś silnie wpisanego obiektu w modelu obiektów domeny, SOAP jest lepiej przystosowany do tego celu.

2. „Dlaczego i tak pisać usługę REST, która zwraca XML?”

   Cóż, tak, to może być głupie. Ale to zależy od tego, jaki jest XML. Jeśli gdzieś istnieje jasno określony schemat, to nie ma dwuznaczności. Na przykład adresy URL WSDL można traktować jako rodzaj usługi WWW zgodnej ze specyfikacją REST do pobierania informacji o usłudze WWW. W takim przypadku dodanie narzutu innego żądania SOAP byłoby bezcelowe.

   Ogólnie rzecz biorąc, REST wygrywa, gdy przesyłaną zawartość można traktować jako plik, jako pojedynczą jednostkę . SOAP wygrywa, gdy zawartość musi być traktowana jako obiekt ze składnikami .

3. „Słyszałem narzekanie, że w przypadku SOAP masz„ narzut ”koperty SOAP. Czy w dzisiejszych czasach naprawdę musimy się martwić o garść bajtów?”

   Tak. Nie w każdych okolicznościach, ale są witryny o dużym natężeniu ruchu, w których ma to znaczenie. Czy wystarczy różnica, aby przeważyć nad semantycznymi różnicami używania SOAP zamiast REST? Wątpię. Jeśli robisz protokół zdalnej komunikacji obiektowej i liczba bajtów robi różnicę, SOAP prawdopodobnie i tak nie jest dla ciebie narzędziem - może zamiast tego powinieneś użyć CORBA lub DCOM.

4. „Słyszałem argument, że za pomocą REST możesz po prostu wrzucić adres URL do przeglądarki i zobaczyć dane”.

   Tak, i to jest duży argument przemawiający za REST, jeśli ma sens przeglądanie danych w przeglądarce . Na przykład w przypadku danych obrazu jest to łatwy sposób na debugowanie usługi - po prostu wklej adres URL w pasku adresu przeglądarki i zobacz, jak wygląda obraz. Lub jeśli zwrócone dane są w formacie XML, a masz odwołanie do arkusza stylów XML, który jest renderowany w czytelnym formacie HTML w przeglądarce, możesz skorzystać z semantycznych znaczników i łatwej wizualizacji w jednym pakiecie. Ale masz rację, ta korzyść zanika głównie podczas pracy z bardziej złożonymi schematami uwierzytelniania. Jeśli nie możesz zakodować wszystkich swoich informacji uwierzytelniających w każdym żądaniu HTTP , argumentowałbym, że w ogóle nie liczy się to jako REST.

5. „Dlaczego potrzebujemy„ czytelnego ”adresu URL dla każdego zasobu? Jeśli używamy narzędzia do implementacji usługi, czy naprawdę zależy nam na rzeczywistym adresie URL?

   Cóż, to zależy. Dlaczego potrzebujemy czytelnych adresów URL dla dowolnego zasobu w sieci? Możesz przeczytać esej Tima Bernersa-Lee Cool URIs Don't Change dla uzasadnienia, ale w zasadzie, o ile zasób może być nadal przydatny w przyszłości, identyfikator URI dla tego zasobu powinien pozostać taki sam.

   Oczywiście w przypadku zasobów przejściowych (takich jak łącze „dzisiejsze pieniądze” w eseju) nie ma takiej potrzeby, ponieważ potrzeba odniesienia się do zasobu znika, gdy odpowiedni zasób zniknie. Ale w przypadku bardziej trwałych zasobów (takich jak na przykład pytania StackOverflow lub filmy w IMDB) chcesz mieć adres URL, który będzie działał wiecznie. Projektując usługę internetową, musisz zdecydować, czy same zasoby mogą przetrwać Twoją usługę, a jeśli tak, to prawdopodobnie REST jest właściwą drogą.

Dla przypomnienia, tak, tworzyłem strony internetowe na długo przed powstaniem NetFlix czy Twittera. I nie, nie miałem jeszcze potrzeby ani możliwości wdrożenia klienta do usług NetFlix lub Twittera. Ale nawet jeśli ich usługi są okropnie trudne w obsłudze, nie oznacza to, że technologia, na której zaimplementowali swoje usługi, jest zła - tylko, że te dwie implementacje są złe.

Krótko mówiąc: REST i SOAP to tylko narzędzia . Każdy z nich ma mocne i słabe strony. Jeśli jedynym posiadanym narzędziem jest młotek, to każdy problem wygląda jak gwóźdź. Poznaj więc oba narzędzia i naucz się ich poprawnie używać, a następnie wybierz odpowiednie narzędzie do każdego zadania.

Uczciwe pytanie zasługuje na szczerą odpowiedź. Ale po pierwsze, dlaczego wykorzystałeś tekst tego pytania jako odpowiedź na inne pytanie, jeśli nie sądziłeś, że ma ono charakter retoryczny?

Tak czy siak:

1. „ Istnieją narzędzia dla wszystkich współczesnych języków / frameworków / platform do odczytywania w WSDL i wyprowadzania klas proxy i klientów. Implementacja usługi REST jest wykonywana ręcznie, czytając dokumentację ”.

   Tak jak dostawcy przeglądarek przeczytali i ponownie przeczytali specyfikację HTML 4.01 w górę iw dół, aby spróbować zaimplementować spójne wrażenia z przeglądania. Czy zastanawiałeś się nad faktem, że przeglądarki zostały wynalezione na długo przed bankowością internetową i przepełnieniem stosu, a mimo to możesz użyć przeglądarki do tego. Jest to możliwe tylko dlatego, że wszyscy zgadzają się na używanie HTML (i powiązanych formatów, takich jak CSS, JS, JPEG itp.).

   Blogowanie nie jest w rzeczywistości takie nowe i ktoś wymyślił AtomPub, który umożliwia dowolnemu oprogramowaniu do blogowania dostęp i aktualizowanie postów na blogu, podobnie jak każda przeglądarka internetowa może uzyskać dostęp do dowolnej strony internetowej. To całkiem fajne i działa z powodu ograniczeń RESTful narzuconych przez protokół.

   Jednak w przypadku Twittera i Netflix nie ma powszechnej zgody, że „wszystkie istniejące mikroblogi powinny używać aplikacji typu media / tweet”, głównie dlatego, że mikroblogowanie jest tak nowe. Być może za kilka lat kilka usług mikroblogowych będzie korzystać z tego samego API, aby Twitter, Facebook, Identica i mogły współpracować. Żaden z ich istniejących interfejsów API nie jest w pobliżu RESTful, niezależnie od tego, jak bardzo twierdzą, więc nie oczekuję, że stanie się to wkrótce.

   „ Co więcej, podczas wdrażania tych dwóch usług musisz„ zgadywać ”, co będzie w potoku, ponieważ nie ma prawdziwego schematu ani dokumentu referencyjnego ”.

   Uderzyłeś w sedno. REST dotyczy dystrybucji i hipermediów, i to właściwie podsumowuje. Przeglądarka sprawdza, co otrzymuje z żądania i pokazuje to użytkownikowi. Strona HTML zwykle generuje znacznie więcej żądań GET, na przykład CSS, skrypty i obrazy. Obraz jest zwykle renderowany tylko na ekranie, wykonywany jest JavaScript i tak dalej. Za każdym razem przeglądarka robi to, co robi, ponieważ znalazła łącze w tagu <img>lub, <style>a typem nośnika odpowiedzi był image/jpeglub text/css.

   Jeśli Twitter tworzy interfejs API oparty na hipermediach, prawdopodobnie zawsze zwróci komunikat za application/tweetkażdym razem, gdy klikniesz łącze do tweeta, ale klient nigdy nie powinien go zakładać i zawsze sprawdzać, co dostaje, zanim zacznie działać.

2. „ Dlaczego i tak pisać usługę REST, która zwraca XML? ”

   Wszystko sprowadza się do typów mediów. Podobnie jak w przypadku HTML, jeśli zobaczysz element, o którym nie masz pojęcia, co właściwie oznacza, specyfikacja HTML poinstruuje cię, abyś je zignorował i przetworzył „treść” tagu, jeśli taki ma. Podobnie, specyfikacja atomu instruuje cię, aby ignorować nieznane elementy i obce znaczniki (z różnych przestrzeni nazw) i nie przetwarzać treści (IIRC).

   Projektowanie typów mediów dla ogólnych domen problemowych (jak w typie mediów HTML dla domeny z problemami z tekstem sformatowanym ) jest bardzo trudne. Tworzenie typów mediów dla bardzo wąskich dziedzin problemowych jest prawdopodobnie znacznie łatwiejsze (jak tweet). Ale zawsze dobrym pomysłem jest zaprojektowanie pod kątem rozszerzalności i określenie, jak klienci (i serwery) mają reagować, gdy zobaczą elementy lub elementy danych, które nie pasują do specyfikacji. Na przykład JPEG ma typ rekordu specyficzny dla aplikacji (np. APP1), który jest używany do przechowywania wszelkiego rodzaju metadanych.

3. „ Słyszałem narzekanie, że w przypadku SOAP masz„ narzut ”koperty SOAP. Czy w dzisiejszych czasach naprawdę musimy się martwić o garść bajtów? ”

   Nie, nie mamy. REST absolutnie nie polega na tym, aby być wydajnym w sieci, w rzeczywistości chodzi o wymianę wydajności. Wydajność REST pochodzi z możliwości buforowania włączonych przez wszystkie inne ograniczenia: Uwagi do rozprawy Fieldinga : Kompromis polega jednak na tym, że jednolity interfejs degraduje wydajność, ponieważ informacje są przekazywane w standardowej formie, a nie takiej, która jest specyficzna dla potrzeb aplikacji. Interfejs REST został zaprojektowany tak, aby był wydajny w przypadku przesyłania dużych ilości danych w hipermediach, optymalizując go pod kątem typowego przypadku sieci WWW, ale w rezultacie uzyskując interfejs, który nie jest optymalny dla innych form interakcji architektonicznych. Nie sądzę, aby narzut liczby bajtów koperty SOAP był uzasadniony.

4. „ Słyszałem argument, że za pomocą REST możesz po prostu wrzucić adres URL do przeglądarki i zobaczyć dane ”.

   Tak, to także nieprawidłowy argument. To nie działa w ten sposób. Nawet jeśli zadziałało, większość wąskich interfejsów API REST używa typów multimediów, o których przeglądarki nie mają pojęcia i nadal nie będą działać.

   Ale istnieje o wiele więcej możliwości testowania interfejsu API opartego na protokole HTTP niż przeglądarka, takich jak narzędzia wiersza poleceń lub rozszerzenia przeglądarki, które pozwalają kontrolować prawie każdy aspekt żądania HTTP, sprawdzać nagłówki odpowiedzi i znajdować linki do śledzenia. Ale mimo to nie jest to nawet tak proste, jak generowanie kodów pośredniczących WSDL i tworzenie programu w trzech wierszach, który i tak wywoła funkcję.

5. „ Dlaczego potrzebujemy«czytelny»URL dla każdego zasobu? Gdybyśmy przy użyciu narzędzia do wykonania usługi, czy naprawdę dbają o rzeczywistej zawartości? ”

   Jeśli spojrzysz na to, jak działa sieć, jestem prawie pewien, że ludzie są ogólnie zadowoleni, że identyfikator URI strony Wikipedii wygląda tak, http://en.wikipedia.org/wiki/Stack_overflowa nie tak http://en.wikipedia.org/wiki/?oldid=376349090. Ale w rzeczywistości REST nie jest ważny. Ważną rzeczą, którą należy podjąć, jest wybranie umieszczenia odpowiednich danych w identyfikatorze URI, które prawdopodobnie nie ulegną zmianie. Możesz pomyśleć, że identyfikator bazy danych nigdy się nie zmieni, ale co się stanie, gdy dwa zestawy danych będą musiały zostać scalone? Wszystkie klucze podstawowe ulegają zmianie. Tytuł strony (Stack_overflow) nie ulegnie zmianie.

Przepraszam za długą odpowiedź, ale uważam, że to pytanie jest ważne i nie zostało wcześniej omówione tutaj na SO. Jestem pewien, że Darrel Miller doda swoją odpowiedź, gdy wróci.

Edycja: formatowanie

Martin Fowler ma post na temat modelu dojrzałości Richardsona, który świetnie się spisuje, wyjaśniając różnicę między SOAP a REST.

WSDL i inne protokoły na poziomie dokumentu są nadmiarowe. Protokół HTTP obsługuje znacznie bogatszy zestaw operacji, poza samym udostępnianiem dokumentów i przesyłaniem formularzy.

Zwolennicy REST nie są zadowoleni z tej nadmiarowości.