Wygląda na to, że REST to tylko zbiór konwencji dotyczących używania protokołu HTTP . Zastanawiam się, jaką korzyść dają te konwencje. Czy ktoś wie?

Nie sądzę, abyś dostał dobrą odpowiedź na to pytanie, częściowo dlatego, że nikt tak naprawdę nie zgadza się co do tego, czym jest REST . Strona wikipedii jest pełna frazesów i mało objaśnień. Warto przejrzeć stronę dyskusji, aby zobaczyć, jak bardzo ludzie się z tym nie zgadzają. O ile mogę jednak stwierdzić, REST oznacza to:

Zamiast losowo nazwane setter i getter adresy i korzystania GETdla wszystkich pobierające i POSTdla wszystkich ustawiaczy, staramy się mieć adresy URL zidentyfikowanie zasobów, a następnie za pomocą działań HTTP GET, POST, PUTi DELETErobić rzeczy z nimi. Więc zamiast

GET /get_article?id=1
POST /delete_article   id=1

Ty byś zrobił

GET /articles/1/
DELETE /articles/1/

A potem POSTi PUTodpowiadają operacjom „Utwórz” i „Aktualizuj” (ale nikt nie zgadza się, w którą stronę).

Myślę, że argumenty buforowania są błędne, ponieważ ciągi zapytań są zwykle buforowane, a poza tym tak naprawdę nie musisz ich używać. Na przykład django sprawia, że ​​coś takiego jest bardzo łatwe i nie powiedziałbym, że to REST:

GET /get_article/1/
POST /delete_article/     id=1

Lub po prostu umieść czasownik w adresie URL:

GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/

W tym przypadku GEToznacza coś bez skutków ubocznych i POSToznacza coś, co zmienia dane na serwerze. Myślę, że jest to być może trochę jaśniejsze i łatwiejsze, zwłaszcza, że ​​można uniknąć całego PUT-vs- POST. Dodatkowo możesz dodać więcej czasowników, jeśli chcesz, więc nie jesteś sztucznie związany z tym, co oferuje HTTP. Na przykład:

POST /hide/article/1/
POST /show/article/1/

(Lub cokolwiek, trudno wymyślić przykłady, dopóki się nie wydarzy!)

Podsumowując, widzę tylko dwie zalety:

1. Twój internetowy interfejs API może być bardziej przejrzysty i łatwiejszy do zrozumienia / odkrycia.
2. Podczas synchronizowania danych ze stroną internetową prawdopodobnie łatwiej jest użyć REST, ponieważ możesz po prostu powiedzieć synchronize("/articles/1/")lub cokolwiek. To zależy w dużej mierze od twojego kodu.

Myślę jednak, że jest kilka dość dużych wad:

1. Nie wszystkie akcje są łatwo mapowane na CRUD (tworzenie, odczytywanie / odzyskiwanie, aktualizowanie, usuwanie). Możesz nawet nie mieć do czynienia z zasobami typu obiektowego.
2. To dodatkowy wysiłek dla wątpliwych korzyści.
3. Nieporozumienie co do tego, w którą stronę PUTi POSTsą. W języku angielskim mają na myśli podobne rzeczy („Zamierzam umieścić / opublikować ogłoszenie na ścianie”).

Podsumowując, powiedziałbym: jeśli naprawdę nie chcesz włożyć dodatkowego wysiłku lub jeśli twoja usługa naprawdę dobrze odwzorowuje operacje CRUD, zapisz REST dla drugiej wersji twojego API.

Właśnie natknąłem się na inny problem z REST: nie jest łatwo zrobić więcej niż jedną rzecz w jednym żądaniu lub określić, które części obiektu złożonego chcesz uzyskać. Jest to szczególnie ważne w przypadku telefonów komórkowych, gdzie czas podróży w obie strony może być znaczący, a połączenia zawodne. Na przykład załóżmy, że otrzymujesz posty na osi czasu na Facebooku. „Czysty” sposób REST byłby czymś w rodzaju

GET /timeline_posts     // Returns a list of post IDs.
GET /timeline_posts/1/  // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....

Co jest trochę śmieszne. API Facebooka to całkiem niezłe IMO, więc zobaczmy, co robią:

Domyślnie większość właściwości obiektu jest zwracana podczas tworzenia zapytania. Możesz wybrać pola (lub połączenia), które chcesz zwrócić za pomocą parametru zapytania „pola”. Na przykład ten adres URL zwróci tylko identyfikator, imię i zdjęcie Bena: https://graph.facebook.com/bgolub?fields=id,name,picture

Nie mam pojęcia, jak zrobiłbyś coś takiego z REST, a gdybyś to zrobił, czy nadal by się to liczyło jako REST. Z pewnością zignorowałbym każdego, kto próbuje ci powiedzieć, że nie powinieneś tego robić (zwłaszcza jeśli powodem jest „ponieważ to nie jest REST”)!

Mówiąc najprościej, REST oznacza używanie HTTP tak, jak powinno.

Zapoznaj się z rozprawą Roya Fieldinga o REST . Myślę, że każda osoba zajmująca się tworzeniem stron internetowych powinna ją przeczytać.

Uwaga: Roy Fielding jest również jednym z kluczowych sterowników protokołu HTTP.

Aby wymienić niektóre z zalet:

• Prosty.
• Możesz dobrze wykorzystać pamięć podręczną HTTP i serwer proxy, aby pomóc sobie z dużym obciążeniem.
• Pomaga zorganizować nawet bardzo złożoną aplikację w proste zasoby.
• Ułatwia to nowym klientom korzystanie z Twojej aplikacji, nawet jeśli nie zaprojektowałeś jej specjalnie dla nich (prawdopodobnie dlatego, że nie było ich w pobliżu, kiedy tworzyłeś aplikację).

Mówiąc najprościej: BRAK .

Zapraszam do głosowania przeciw, ale nadal uważam, że nie ma żadnych prawdziwych korzyści w porównaniu z protokołem HTTP innym niż REST. Wszystkie aktualne odpowiedzi są nieprawidłowe. Argumenty z aktualnie najczęściej głosowanej odpowiedzi:

• Prosty.
• Możesz dobrze wykorzystać pamięć podręczną HTTP i serwer proxy, aby pomóc sobie z dużym obciążeniem.
• Pomaga zorganizować nawet bardzo złożoną aplikację w proste zasoby.
• Ułatwia to nowym klientom korzystanie z Twojej aplikacji, nawet jeśli nie zaprojektowałeś jej specjalnie dla nich (prawdopodobnie dlatego, że nie było ich w pobliżu, kiedy tworzyłeś aplikację).

1. Proste

Dzięki REST potrzebujesz dodatkowej warstwy komunikacyjnej dla skryptów po stronie serwera i klienta => jest to w rzeczywistości bardziej skomplikowane niż użycie protokołu HTTP innego niż REST.

2. Buforowanie

Buforowaniem można sterować za pomocą nagłówków HTTP wysyłanych przez serwer. REST nie dodaje żadnych funkcji, których brakuje w trybie innym niż REST.

3. Organizacja

REST nie pomaga w organizowaniu rzeczy. To zmusza do korzystania z API obsługiwanego przez biblioteki po stronie serwera, którego używasz. Możesz zorganizować swoją aplikację w ten sam sposób (lub lepiej), gdy używasz podejścia innego niż REST. Np. Patrz Model-View-Controller lub routing MVC .

4. Łatwy w użyciu / implementacji

Wcale nieprawda. Wszystko zależy od tego, jak dobrze zorganizujesz i udokumentujesz swoją aplikację. REST nie poprawi w magiczny sposób Twojej aplikacji.

IMHO Największą zaletą REST jest redukcja sprzężenia klient / serwer. Z czasem znacznie łatwiej jest rozwijać interfejs REST bez uszkadzania istniejących klientów.

Wykrywalność

Każdy zasób ma odniesienia do innych zasobów, w hierarchii lub w linkach, więc można je łatwo przeglądać. Jest to korzyść dla człowieka, który rozwija klienta, oszczędzając mu ciągłego konsultowania się z lekarzami i oferowania sugestii. Oznacza to również, że serwer może jednostronnie zmieniać nazwy zasobów (o ile oprogramowanie klienta nie koduje adresów URL na stałe).

Zgodność z innymi narzędziami

Możesz przejść do dowolnej części interfejsu API lub użyć przeglądarki internetowej do nawigacji po zasobach. Znacznie ułatwia debugowanie i integrację testową.

Znormalizowane nazwy czasowników

Pozwala określić działania bez konieczności szukania właściwego sformułowania. Wyobraź sobie, że metody pobierające i ustawiające OOP nie byłyby ustandaryzowane, a niektórzy używaliby zamiast tego retrievei define. Musiałbyś zapamiętać poprawny czasownik dla każdego indywidualnego punktu dostępu. Świadomość, że istnieje tylko kilka dostępnych czasowników, przeciwdziała temu problemowi.

Stan standaryzowany

Jeśli jesteś GETzasobem, który nie istnieje, możesz być pewien, że wystąpi 404błąd w RESTful API. Porównaj to z interfejsem API innym niż RESTful, który może powrócić {error: "Not found"}zawinięty w Bóg wie, ile warstw. Jeśli potrzebujesz dodatkowego miejsca na napisanie wiadomości do programisty po drugiej stronie, zawsze możesz użyć treści odpowiedzi.

Przykład

Wyobraź sobie dwa interfejsy API o tej samej funkcjonalności, jeden po REST, a drugi nie. Teraz wyobraź sobie następujących klientów dla tych interfejsów API:

Spokojny:

GET /products/1052/reviews
POST /products/1052/reviews       "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10

HTTP:

GET /reviews?product_id=1052
POST /post_review?product_id=1052                  "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10

Teraz pomyśl o następujących pytaniach:

• Jeśli pierwszy telefon od każdego klienta zadziałał, czy możesz być pewien, że reszta też zadziała?

• Nastąpiła poważna aktualizacja interfejsu API, która mogła zmienić te punkty dostępu lub nie. Ile dokumentów będziesz musiał ponownie przeczytać?

• Czy potrafisz przewidzieć powrót ostatniego zapytania?

• Musisz edytować opublikowaną recenzję (przed jej usunięciem). Czy możesz to zrobić bez sprawdzania dokumentów?

Polecam zajrzeć do książki Ryana Tomayko How I Explained REST to My Wife

Edycja strony trzeciej

Fragment z linku waybackmaschine:

Co powiesz na przykład. Jesteś nauczycielem i chcesz zarządzać uczniami:

• w jakich klasach są,
• jakie stopnie dostają,
• kontakt w razie wypadku,
• informacje o książkach, z których uczysz itp.

Jeżeli układy są oparte na sieci Web, a następnie tam chyba URL dla każdego z rzeczowników zaangażowanych tutaj: student, teacher, class, book, room, etc. ... Gdyby dla każdego adresu URL istniała czytelna dla komputera reprezentacja, byłoby rzeczą trywialną umieszczać nowe narzędzia w systemie, ponieważ wszystkie te informacje byłyby użyteczne w standardowy sposób. ... można zbudować ogólnokrajowy system, który będzie w stanie rozmawiać z każdym z indywidualnych systemów szkolnych w celu zbierania wyników testów.

Każdy z systemów otrzymywałby informacje od siebie za pomocą prostego HTTP GET. Jeśli jeden system musi dodać coś do innego systemu, użyje HTTP POST. Jeśli system chce coś zaktualizować w innym systemie, używa HTTP PUT. Pozostało tylko dowiedzieć się, jak powinny wyglądać dane.

Wszystkim, którzy szukają odpowiedzi na to pytanie, radzę przejrzeć ten „pokaz slajdów” .

Nie mogłem zrozumieć, czym jest REST i dlaczego jest taki fajny, jego zalety i wady, różnice w stosunku do SOAP - ale ten pokaz slajdów był tak genialny i łatwy do zrozumienia, więc teraz jest dla mnie znacznie bardziej jasny niż wcześniej.

Buforowanie.

Istnieją inne, bardziej dogłębne zalety REST, które obracają się wokół możliwości ewolucji poprzez luźne powiązanie i hipertekst, ale mechanizmy buforowania są głównym powodem, dla którego powinieneś dbać o RESTful HTTP.

Jest to zapisane w rozprawie Fieldinga . Ale jeśli nie chcesz dużo czytać:

• zwiększona skalowalność (ze względu na ograniczenia systemu bezstanowego, pamięci podręcznej i warstwowych)
• oddzielony klient i serwer (ze względu na bezstanowe i jednolite ograniczenia interfejsu)
  • klienci wielokrotnego użytku (klient może korzystać z ogólnych przeglądarek REST i semantyki RDF, aby zdecydować, który odsyłacz wybrać i jak wyświetlić wyniki)
  • nie łamiący klienci (klienci psują się tylko przez zmiany semantyki specyficzne dla aplikacji, ponieważ używają semantyki zamiast pewnej wiedzy o API)

• Nadaj każdemu „zasobowi” identyfikator
• Połącz rzeczy razem
• Użyj standardowych metod
• Zasoby z wieloma reprezentacjami
• Komunikuj się bezpaństwowo

Czy można zrobić wszystko tylko za pomocą POST i GET? Tak, czy to najlepsze podejście? Nie dlaczego? ponieważ mamy standardowe metody. Jeśli pomyślisz jeszcze raz, wszystko byłoby możliwe, używając tylko GET ... więc po co w ogóle zawracać sobie głowę korzystaniem z POST? Ze względu na standardy!

Na przykład, myśląc dzisiaj o modelu MVC, możesz ograniczyć swoją aplikację do odpowiadania tylko na określone rodzaje czasowników, takie jak POST, GET, PUT i DELETE. Nawet jeśli pod maską wszystko jest emulowane do POST i GET, czy nie ma sensu używać różnych czasowników dla różnych czynności?

Odkrywanie jest znacznie łatwiejsze w REST. Mamy dokumenty WADL (podobne do WSDL w tradycyjnych usługach sieciowych), które pomogą Ci zareklamować Twoje usługi na świecie. Możesz także użyć odkryć UDDI. W przypadku tradycyjnych protokołów HTTP POST i GET użytkownicy mogą nie znać schematów żądań wiadomości i odpowiedzi, aby do Ciebie zadzwonić.

Jedną z zalet jest to, że możemy przetwarzać dokumenty XML w sposób niesekwencyjny i nierzeczywiste dane XML z różnych źródeł, takich jak obiekt InputStream, adres URL, węzeł DOM ...

@Timmmm, o twojej edycji:

GET /timeline_posts     // could return the N first posts, with links to fetch the next/previous N posts

To znacznie zmniejszyłoby liczbę połączeń

I nic nie stoi na przeszkodzie, aby zaprojektować serwer, który akceptuje parametry HTTP do oznaczania wartości pól, których mogą potrzebować Twoi klienci ...

Ale to jest szczegół.

Znacznie ważniejszy jest fakt, że nie wspomniałeś o ogromnych zaletach stylu architektonicznego REST (dużo lepsza skalowalność dzięki bezpaństwowości serwera; dużo lepsza dostępność także ze względu na bezpaństwowość serwera; dużo lepsze wykorzystanie standardowych usług, takich jak buforowanie przykład, podczas korzystania ze stylu architektonicznego REST; znacznie niższe sprzężenie między klientem a serwerem dzięki zastosowaniu jednolitego interfejsu itp.)

Co do twojej uwagi

„Nie wszystkie akcje są łatwo mapowane na CRUD (tworzenie, odczytywanie / odzyskiwanie, aktualizowanie, usuwanie)”.

: RDBMS również używa podejścia CRUD (SELECT / INSERT / DELETE / UPDATE) i zawsze istnieje sposób na przedstawienie modelu danych i działanie na jego podstawie.

Co do twojego wyroku

„Możesz nawet nie mieć do czynienia z zasobami typu obiektu”

: projekt RESTful jest w zasadzie prostym projektem - ale NIE oznacza to, że jego projektowanie jest proste. Czy widzisz różnicę ? Będziesz musiał dużo pomyśleć o koncepcjach, które Twoja aplikacja będzie reprezentować i którą będzie obsługiwać, co musi zostać przez nią zrobione, jeśli wolisz, aby przedstawić to za pomocą zasobów. Ale jeśli to zrobisz, otrzymasz prostszy i wydajniejszy projekt.

Wyszukiwarki mogą ignorować ciągi zapytań.