Czy serwis internetowy w stylu Netflix lub Twitter powinien używać REST lub SOAP? [zamknięte]

SOAP jest zorientowanym obiektowo, remote procedure call stos technologii. Działa poprzez zbudowanie nowej abstrakcji na bazie istniejącego protokołu (HTTP).

REST jest podejściem zorientowanym na dokument, które po prostu wykorzystuje cechy istniejącego protokołu (HTTP). "Odpoczynek" to tylko hasło-koncepcja jest taka: po prostu Używaj sieci tak, jak została zaprojektowana do pracy!

W odpowiedzi na pytania:

1. "realizacja a Usługa REST trwa nieskończenie dłużej niż wdrożenie usługi SOAP."

   Um, Nie, Nie może być nieskończenie dłużej. W przypadku, 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ę SOAP, jak i REST protokołu, i nie bez powodu prawie nikt nie implementuje wersji SOAP-to dlatego, że jeśli próbujesz uzyskać mapę, to o wiele łatwiej jest po prostu zbudować adres URL i pobrać bajty obrazu z tego adresu URL, niż zawracać sobie głowę zamknięciem go w wiadomości SOAP. Ale tak, Zgadzam się, że jeśli celem usługi internetowej jest przeniesienie jakiegoś silnie wpisanego obiektu w model obiektowy domeny, SOAP lepiej nadaje się do tego zastosowania.

2. "Po co pisać usługę REST, która zwraca XML?"

   Cóż, tak, to może być głupie. Ale to zależy od tego, czym jest XML. Jeśli istnieje jasno określony schemat dla tego gdzieś, to nie ma dwuznaczności. Na przykład adresy URL WSDL można traktować jako rodzaj RESTful web service do pobierania informacji o usłudze internetowej. W tym przypadku dodanie narzutu innego żądania mydła byłoby bezcelowe.

   Ogólnie rzecz biorąc, REST wygrywa, gdy przesyłana zawartość może być traktowana jako plik , jako pojedyncza jednostka . Soap wygrywa, gdy zawartość musi być traktowana jako obiekt z członkowie .

3. "słyszałem skargę, że z mydłem masz "nad głową" koperty mydła. Czy w dzisiejszych czasach naprawdę musimy martwić się o garść bajtów?"

   Tak. Nie w każdych okolicznościach, ale są miejsca o dużym natężeniu ruchu, w których robi to różnicę. Czy wystarczy różnica, aby przeważyć różnice semantyczne używania SOAP zamiast odpoczynku? Wątpię. Jeśli wykonujesz protokół remoting obiektu a ilość bajtów robi różnicę, SOAP i tak nie jest narzędziem dla ciebie . może zamiast tego powinieneś używać Corby lub DCOM.

4. "słyszałem argument, że z REST można po prostu pop URL do przeglądarki i zobaczyć dane."

   Tak, i jest to duży argument na korzyść 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 - wystarczy wkleić adres URL do pasek adresu przeglądarki i zobacz, jak wygląda obraz. Lub jeśli zwracane dane są w formacie XML, a w przeglądarce znajduje się arkusz stylów XML, który renderuje się do czytelnego HTML, wtedy można korzystać z znaczników semantycznych i łatwej wizualizacji w jednym pakiecie. Ale masz rację, ta korzyść głównie wyparowuje podczas pracy z bardziej złożonymi schematami uwierzytelniania. Jeśli nie możesz zakodować wszystkich informacji uwierzytelniających do każdego żądania HTTP , to argumentowałbym, że nie liczy się jako odpoczynek.

5. "Dlaczego potrzebujemy" czytelnego " adresu URL dla każdego Zasobu? Gdybyśmy używali narzędzia do wdrożenia 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 fajne Uri się nie zmieniają dla uzasadnienia, ale zasadniczo, tak długo, jak zasób może być nadal przydatny w przyszłości, URI do tego zasoby powinny pozostać takie same.

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

Dla przypomnienia, tak, tworzyłem strony internetowe od dawna, zanim istniał NetFlix lub Twitter. I nie, nie miałem jeszcze żadnej potrzeby ani możliwości wdrożenia klienta do usług NetFlix lub Twittera. Ale nawet jeśli ich usługi są potwornie trudne do pracy, nie oznacza to, że technologia, na której zaimplementowali swoje usługi, jest zła-tylko, że te dwie implementacje są źle.

Krótko mówiąc: odpoczynek i mydło to tylko narzędzia . Każdy z nich ma mocne i słabe strony. Jeśli jedynym narzędziem, które masz, jest młotek, to każdy problem wygląda jak gwóźdź. Poznaj oba narzędzia i dowiedz się, jak prawidłowo z nich korzystać, a następnie wybierz odpowiednie narzędzie do każdego zadania.

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

W każdym razie:

1. "narzędzia istnieją dla wszystkich współczesnych języków / frameworków/platform do odczytu w WSDL i klasach proxy i klientach wyjściowych. Wdrożenie usługi REST odbywa się ręcznie poprzez czytanie dokumentacji."

   Tak jak sprzedawcy przeglądarek przeczytali i przeczytaj ponownie specyfikację HTML 4.01 w górę iw dół, aby spróbować zaimplementować spójne przeglądanie. Czy zastanawiałeś się nad faktem, że przeglądarki zostały wynalezione na długo przed bankowością internetową i stoskoverflow, a jednak możesz użyć przeglądarki, aby zrobić tylko te rzeczy. Jest to możliwe tylko dlatego, że wszyscy zgadzają się używać HTML (i pokrewnych formatów, takich jak CSS, JS, JPEG itp.).

   Blogowanie nie jest tak nowe, a ktoś wymyślił AtomPub, który pozwala na dowolne blogowanie oprogramowanie do dostępu i aktualizacji postów na blogu, podobnie jak każda przeglądarka internetowa może uzyskać dostęp do dowolnej strony internetowej. To całkiem zgrabne, i działa ze względu na RESTful ograniczeń nałożonych przez protokół.

   Ale w przypadku Twittera i Netflixa nie ma powszechnej zgody, że "wszystkie istniejące mikroblogi będą używać aplikacji typu Media / tweet", głównie dlatego, że mikroblogowanie jest tak nowe. Może za kilka lat kilka usług mikroblogowych osiedli się na tym samym API, aby Twitter, Facebook, Identica i może 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 spodziewam się, że stanie się to tak szybko.

   "Ponadto, podczas wdrażania tych dwóch usług, musisz "zgadywać", co wróci przez rurkę, ponieważ nie ma prawdziwego schematu lub dokumentu referencyjnego."

   Trafiłeś w sedno. REST polega na rozproszeniu i hipermediach, i to w sumie wszystko podsumowuje. Przeglądarka patrzy na co dostaje z żądania i pokazuje go użytkownikowi. Strona HTML zazwyczaj generuje dużo więcej żądań GET, na przykład CSS, skrypty i obrazy. Obraz jest zazwyczaj renderowany tylko na ekranie, wykonywany jest JavaScript i tak dalej. Za każdym razem przeglądarka robi to, co robi, ponieważ znajduje link w znaczniku <img> lub <style>, A Typ nośnika odpowiedzi to image/jpeg lub text/css. Jeśli Twitter tworzy API oparte na hipermediach, prawdopodobnie zawsze zwróci application/tweet za każdym razem, gdy klikniesz link do tweet, ale klient nigdy nie powinien tego zakładać i zawsze sprawdzać, co dostaje, zanim zacznie działać.

2. "Po co pisać usługę REST, która zwraca XML?"

   To wszystko sprowadza się do typów mediów. Podobnie jak HTML, jeśli widzisz element, który nie masz pojęcia, co tak naprawdę oznacza, Specyfikacja HTML nakazuje ci je zignorować i przetworzyć "ciało" tagu, jeśli go posiada. Podobnie, ATOM spec nakazuje ignorowanie nieznanych elementów i obcych znaczników (od różne przestrzenie nazw) i nie przetwarzają ciało (IIRC).

   Projektowanie typów multimediów dla domen problemowych (jak w HTML dla domeny problemowej rich text ) jest bardzo trudne. Tworzenie typów mediów dla bardzo wąskich domen problemowych jest prawdopodobnie o wiele ł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 widzą elementy lub elementy danych, które nie pasują do spec. Na przykład format JPEG ma typ rekordu specyficzny dla aplikacji (np. APP1), który jest używany do przechowywania wszelkiego rodzaju metadanych.

3. "słyszałem skargę, że z mydłem masz "nad głową" koperty mydła. Czy w dzisiejszych czasach naprawdę musimy martwić się o garść bajtów?"

   Odpoczynek nie polega na tym, żeby być wydajnym przez drut, ale na wymianie wydajności drutu. Efektywność odpoczynku wynika z możliwości buforowania włączone przez wszystkie inne ograniczenia: rozprawa Fieldinga uwagi: {40]} kompromis polega jednak na tym, że jednolity interfejs obniża wydajność, ponieważ informacje są przesyłane w znormalizowanej formie, a nie takiej, która jest specyficzna dla potrzeb aplikacji. Interfejs REST został zaprojektowany tak, aby był wydajny dla wielkoziarnistego transferu danych hypermedia, optymalizując dla wspólnego przypadku sieci Web, ale w wyniku interfejsu, który nie jest optymalny dla innych form interakcji architektonicznych. nie sądzę, aby liczba bajtów koperty mydła nad głową była uzasadniona.

4. "słyszałem argument, że z REST można po prostu pop URL do przeglądarki i zobaczyć dane."

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

   Ale są o wiele więcej możliwości niż przeglądarka do testowania interfejsu API opartego na HTTP, 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 odkrywać linki do naśladowania. Ale mimo to, nie jest to tak proste, jak generowanie WSDL stubs i tworzenie programu trzyliniowego do wywoływania funkcji.

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

   Jeśli przyjrzysz się, jak działa sieć, jestem prawie pewien, że ludzie są w zasadzie zadowoleni, że URI dla strony Wikipedii wygląda tak, http://en.wikipedia.org/wiki/Stack_overflow zamiast http://en.wikipedia.org/wiki/?oldid=376349090. Ale w rzeczywistości nie jest ważne, aby odpocząć. Ważną rzeczą, aby spróbować się poprawić, jest wybór umieszczenia odpowiednich danych w URI, które prawdopodobnie się nie zmienią. Może się wydawać, że identyfikator bazy danych nigdy się nie zmieni, ale co się dzieje, gdy dwa zestawy danych muszą być połączone? Wszystkie klucze się zmieniają. Tytuł strony (Stack_overflow) nie ulegnie zmianie.

Przepraszam za długą odpowiedź, ale uważam, że to pytanie jest słuszne i nie było wcześniej poruszane tutaj w ten sposób. Jestem pewien, że Darrel Miller też doda swoją odpowiedź, gdy wróci.

Edit: formatowanie

Martin Fowler ma post na temat modelu dojrzałości Richardsona, który świetnie wyjaśnia różnicę między mydłem a resztą.

WSDL i inne protokoły poziomu dokumentów są zbędne. Protokół HTTP obsługuje znacznie bogatszy zestaw operacji poza tylko obsługą dokumentów i przesyłaniem formularzy.

Zwolennicy odpoczynku czują się nieswojo z tym zwolnieniem.