Jaki jest właściwy sposób na REST?


36

Wszyscy obecnie korzystają z SOA , nawet jeśli niektórzy tak naprawdę nie rozumieją, o co w tym wszystkim chodzi. Więc robią to źle. Używając tego jako analogii, wiem, czym jest REST (a przynajmniej tak mi się wydaje) i chcę to zrobić. Ale chcę to zrobić dobrze.

Więc moje pytanie brzmi: jaki jest właściwy sposób na REST?


1
Wiki przepełnienia stosu „rest” tag wydaje się być tak blisko, jak to tylko możliwe, do zasobu kanonicznego w kontekście sieci stosu wymiany
gnat

17
Po prostu zamykam na chwilę oczy ... może udam się na przejażdżkę rowerem, a potem położyłem się.
Edward Strange

Czy usługa REST nie używa po prostu adresu URL, takiego jak mydomain.com/accounts i czasownika HTTP, aby wywołać operację? Gdzie czasownik wskazuje, czy chcesz uzyskać, utworzyć, zaktualizować lub usunąć dane? Kiedy myślę o REST, myślę o tym.
The Muffin Man

2
@Nick, to najczęstsza interpretacja, „prawdziwa” jest o wiele trudniejsza do zrozumienia i (o ile mogę powiedzieć) o wiele trudniejsza do znalezienia w rzeczywistości gdziekolwiek wdrożona ... (patrz odpowiedź Wilka)
Benjol

3
@Nick twoje zrozumienie nie jest REST, to RPC przez HTTP .

Odpowiedzi:


30

Cóż, istnieje wiele sposobów na nauczenie się, jak zbudować aplikację internetową RESTful i nie, nie ma wyjątkowej właściwej metody. RESTful nie jest standardem, ale wykorzystuje zestaw standardów (HTTP, URI, Mime Type, ...).

Zacznij od tego: Jak wyjaśniłem REST mojej żonie

Następnie wykonaj następujące czynności: RESTful Web Services Cookbook

A potem włóż cały swój wysiłek w tworzenie aplikacji internetowych, ponieważ najlepszym sposobem na naukę jest przeprowadzanie eksperymentów i możesz wiele nauczyć się na własnych błędach;)

Nie martw się, jeśli Twoje pierwsze aplikacje internetowe nie będą całkowicie ODPOCZYNEK: znajdziesz sposób, aby to zrobić!

Cytując Obi-Wana Kenobiego, „niech moc będzie z tobą!” ;)

EDYTOWAĆ

Ok, pozwól mi być bardziej konkretny. Chcesz stworzyć RESTful webapp, co? Cóż, jak powiedziałem, istnieje wiele sposobów, aby to zrobić, ale jest to główna wskazówka.

Definicja

REST (Representational State Transfer) to styl architektury oprogramowania dla systemu rozproszonego (np. WWW). Nie jest to standard, ale wykorzystuje zestaw standardów: HTTP, AJAX, HTML, URI, Mime Type itp. Mówimy o reprezentacji zasobu, a nie o samym zasobie. Zaczerpnięte z „Jak wyjaśniłem REST mojej żonie”:

Żona : strona internetowa jest zasobem?

Ryan : W pewnym sensie. Strona internetowa jest reprezentacją zasobu. Zasoby to tylko koncepcje.

Ograniczenia architektury

  • Klient-serwer : klient i serwer są oddzielone przez jednolity interfejs (opisany poniżej).
  • Bezstanowy : komunikacja serwer-klient odbywa się bez zapisywania określonego stanu klienta na serwerze.
  • Możliwe do buforowania : klient może mieć już bufor odpowiedzi na złożone żądania.
  • System warstwowy : klient nie wie, czy jest bezpośrednio połączony z serwerem końcowym, czy też komunikacja odbywa się za pośrednictwem pośredników.

Jednolity interfejs

  • Identyfikacja zasobów: każdy zasób musi być identyfikowany przez URI.
  • Protokół : aby uzyskać komunikację między klientem a serwerem, należy wcześniej wykonać protokół. Każde żądanie może mieć odpowiedni typ MIME (application / xml, text / html, application / rdf + xml itp.), Odpowiednie nagłówki i odpowiednią metodę HTTP (patrz opis CRUD poniżej).

CRUD

Ok, widzieliśmy, że do identyfikacji zasobów możemy użyć URI, ale potrzebujemy czegoś innego do akcji (dodawania, modyfikowania, usuwania itp.): Wielkie powitanie w CRUD (tworzenie, czytanie, aktualizowanie i usuwanie).

  • Utwórz { HTTP: POST } { SQL: INSERT } => utwórz nowy zasób
  • Przeczytaj { HTTP: GET } { SQL: SELECT } => zdobądź zasób
  • Zaktualizuj { HTTP: PUT } { SQL: UPDATE } => zmodyfikuj zasób
  • Usuń { HTTP: DELETE } { SQL: DELETE } => usuń zasób

Teraz, jeśli chodzi o PUT i DELETE, mogą pojawić się pewne problemy techniczne (dostaniesz je w formularzu HTML): często programiści omijają ten problem za pomocą POST dla każdego żądania „PUT” i „DELETE”. Oficjalnie musisz użyć PUT i DELETE. Nawiasem mówiąc, rób, co chcesz. Moje doświadczenie zmusza mnie do korzystania z POST i GET za każdym razem.

--- Należy użyć następnej części, ale nie jest to więź REST: dotyczy ona danych powiązanych ---

URI

Streszczenie URI ze szczegółów technicznych! Pożegnaj się z URI w następujący sposób:

http://www.example.com/index.php?query=search&id=9823&date=08272012

Ponowne zaprojektowanie URI! Wybierz powyższy link i zmień go w następujący sposób:

http://www.example.com/search/2012/08/27/9823

To o wiele lepsze, prawda? Można to zrobić przez:

Kolejna rzecz: użyj innego identyfikatora URI do reprezentowania różnych zasobów:

Uwaga : about.html i about.rdf nie są plikami! Mogą być wynikiem transformacji XSLT!

Negocjacje treści

Jeśli osiągnąłeś ten punkt, gratulacje! Prawdopodobnie jesteś gotowy, aby uzyskać więcej abstrakcyjnych koncepcji, ponieważ wchodzimy w szczegóły techniczne Semantic Web;) Cóż, gdy twój klient chce zasobu, zwykle wysyła następujące żądanie:

GET http://www.example.com/about
Accept: application/rdf+xml

Ale serwer nie odpowie na about.rdf, ponieważ ma inny identyfikator URI ( http://www.example.com/about.rdf ). Spójrzmy więc na wzór 303 ! Serwer zwróci to:

303 See Other
Location: http://www.example.com/about.rdf

Klient podąży za linkiem zwróconym w następujący sposób:

GET http://www.example.com/about.rdf
Accept: application/rdf+xml

Na koniec serwer zwróci żądany zasób:

200 OK
about.rdf

Nie martw się: aplikacja kliencka nic z tego nie zrobi! Wzorzec 303 musi zostać wykonany przez aplikację serwera, a przeglądarka zajmie się resztą;)

Wniosek

Często teoria jest daleka od praktyki. Tak, teraz już wiesz, jak zaprojektować i opracować aplikację RESTful, ale powyższa wskazówka to tylko wskazówka. Znajdziesz najlepszy sposób na budowanie aplikacji internetowych i prawdopodobnie nie będzie to to, czego chce teoria. Nie przejmuj się: D!

Bibliografia

RESTful Web Services, Sameer Tyagi

Interfejsy API REST muszą być sterowane hipertekstem, Roy Thomas Fielding

Usługi RESTful Web: podstawy, Alex Rodriguez

Przepływ pracy REST Webbera


1
Możesz rozważyć dodanie tego linku , który jest najbardziej kompletnym przewodnikiem, z jakim się zetknąłem.
Benjol

Widziałem używane PUT i POST z zamienionymi znaczeniami (w odniesieniu do twojej odpowiedzi): POST -> tworzenie, PUT -> aktualizacja. Masz pomysł, które znaczenie jest szerzej stosowane?
Andres F.

@Andres F .: jcalcote.wordpress.com/2008/10/16/... mówi: Utwórz = PUT, jeśli wysyłasz pełną treść określonego zasobu (URL). Utwórz = POST, jeśli wysyłasz polecenie do serwera, aby utworzyć podwładnego określonego zasobu, używając jakiegoś algorytmu po stronie serwera. Update = PUT, jeśli aktualizujesz pełną zawartość określonego zasobu. Aktualizacja = POST, jeśli żądasz od serwera aktualizacji jednego lub więcej podwładnych określonego zasobu.
Wilk

@Benjol: Zamierzam edytować z twoją sugestią;) Dzięki!
Wilk

1
@ Wilk Kilka rzeczy do rozważenia! Prawdopodobnie dlaczego nikt nie ma racji: P
Andres F.

5

książka biblijna REST lub coś takiego ...

Książka biblijna nie jest konieczna; Miałem te same dokładne pytania i nauczyłem się wszystkiego, co potrzebowałem lub chciałem wiedzieć o REST, czytając te trzy artykuły:

  1. Wprowadzenie do HTTP i REST dla początkujących od Net Tuts +
  2. Usługi RESTful Web: podstawy od IBM developerWorks
  3. RESTful HTTP w praktyce od InfoQ

Ale chcę to zrobić dobrze.

Jak przeczytasz w powyższych artykułach, kluczem jest pomyślenie o dostępnych elementach aplikacji jako „zasobach”, które można tworzyć, pobierać, aktualizować lub usuwać za pomocą istniejących „czasowników” HTTP: GET, PUT, POST , KASOWAĆ.

Ponadto poznaj różnicę między PUT a POST i kiedy ich używać. GET, PUT i DELETE powinny być transakcjami idempotentnymi, POST nie.

Podczas komunikacji z klientem należy również właściwie wykorzystywać kody stanu HTTP .

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.