Pytanie Czym dokładnie jest programowanie RESTful?


Czym dokładnie jest programowanie RESTful?


3630
2018-03-22 14:45


pochodzenie


zobacz także odpowiedź pod poniższym linkiem stackoverflow.com/a/37683965/3762855 - Ciro Corvino
REST może być teraz nieco stary;) youtu.be/WQLzZf34FJ8 - Vlady Veselinov
Zobacz także ten link, aby uzyskać więcej informacji news.ycombinator.com/item?id=3538585 - Ashraf.Shk786
Korekty do zaakceptowanej odpowiedzi tutaj. stackoverflow.com/questions/19843480/...  Lub tu roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven  Lub tu web.archive.org/web/20130116005443/http://tomayko.com/writings/... - kushalvm
Przyjemna obserwacja @ OLIVER.KOO. Po prostu spytałem go, kiedy to było coś nowego. Dużo się rzucało, ale niewielu ludzi wiedziało o co chodzi. Przynajmniej tego nie zrobiłem i wydaje mi się, że to pytanie pomogło im, ponieważ chcieli się dowiedzieć. - hasen


Odpowiedzi:


Na styl architektoniczny nazywa REST (transfer reprezentacyjny) opowiada się za tym, aby aplikacje internetowe używały takiego samego protokołu HTTP pierwotnie przewidywano. Powinny używać wyszukiwań GET upraszanie. PUT, POST, i DELETE upraszanie powinny być używane dla mutacja, tworzenie i usuwanie.

Zwolennicy REST preferują adresy URL, takie jak

http://myserver.com/catalog/item/1729

ale architektura REST nie wymaga tych "ładnych adresów URL". Żądanie GET z parametrem

http://myserver.com/catalog?item=1729

jest tak samo RESTful.

Pamiętaj, że żądania GET nigdy nie powinny być używane do aktualizacji informacji. Na przykład żądanie GET o dodanie przedmiotu do koszyka

http://myserver.com/addToCart?cart=314159&item=1729

nie byłoby właściwe. Żądania GET powinny być idempotent. Oznacza to, że dwukrotne wystawienie wniosku nie powinno różnić się od wystawienia go raz. To właśnie sprawia, że ​​żądania są buforowane. Żądanie "dodaj do koszyka" nie jest idempotentne - wystawienie go dwukrotnie powoduje dodanie dwóch kopii przedmiotu do koszyka. Wniosek POST jest wyraźnie odpowiedni w tym kontekście. Tak więc nawet RESTful aplikacja internetowa potrzebuje swojego udziału w żądaniach POST.

To pochodzi z doskonałej książki Interfejs JavaServer książka Davida M. Geary'ego.


541
2018-04-15 11:26



Lisiting Available Idempotent Operations: GET (Safe), PUT i DELETE (wyjątek jest wymieniony w tym linku restapitutorial.com/lessons/idempotency.html). Dodatkowe odniesienie do bezpiecznych i idempotentnych metod w3.org/Protocols/rfc2616/rfc2616-sec9.html - Abhijeet
a) istotną kwestią dotyczącą GET jest bezpieczeństwo, a nie idempotencja, b) @Abhijeet: RFC 2616 został przestarzały w 2014 r .; patrz RF 7230ff. - Julian Reschke
To jest źle. Przeczytaj to, aby uzyskać prawidłową interpretację REST roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven  albo to stackoverflow.com/questions/19843480/... - kushalvm
@kushalvm Ta akademicka definicja REST nie jest używana w praktyce. - Elliott Beach
REST nigdy nie był przeznaczony do użycia w webowych interfejsach API, tylko w przypadku zasobów statycznych, i one są sterowany hipertekstem. Jednak Fielding, w całej swojej akademickiej naiwności, myślał, że zostaną one utrzymane przy pomocy wszystkich tych czasowników HTTP bezpośrednio z przeglądarki, co nie jest praktyczne w żadnym razie ani w formie. REST to nic innego jak tylko kilka bezużytecznych modnych powiedzonek i powinno zostać porzucone JAK NAJSZYBCIEJ. - Vadim Ferderer


ODPOCZYNEK jest podstawową zasadą architektury sieci. Niesamowitą cechą internetu jest fakt, że klienci (przeglądarki) i serwery mogą wchodzić w interakcje w złożony sposób, bez wcześniejszego powiadomienia klienta o serwerze i zasobach, które on obsługuje. Kluczowym ograniczeniem jest to, że zarówno serwer, jak i klient muszą zgodzić się na głoska bezdźwięczna używane, co w przypadku sieci jest HTML.

Interfejs API zgodny z zasadami ODPOCZYNEK nie wymaga od klienta znajomości struktury interfejsu API. Zamiast tego serwer musi podać wszelkie informacje, jakich potrzebuje klient, aby wejść w interakcję z usługą. Na Formularz HTML jest tego przykładem: serwer określa lokalizację zasobu i wymagane pola. Przeglądarka nie wie z góry, gdzie przesłać informacje, i nie wie z wyprzedzeniem, jakie informacje należy przesłać. Obie formy informacji są w całości dostarczane przez serwer. (Ta zasada nazywa się HATEOAS: Hypermedia jako silnik stanu aplikacji.)

A więc, w jaki sposób ma to zastosowanie HTTPi jak można go wdrożyć w praktyce? HTTP jest zorientowany na czasowniki i zasoby. Dwa czasowniki w głównym nurcie to GET i POST, które, jak sądzę, każdy rozpozna. Jednak standard HTTP definiuje kilka innych, takich jak PUT i DELETE. Te czasowniki są następnie stosowane do zasobów, zgodnie z instrukcjami dostarczonymi przez serwer.

Na przykład: Wyobraźmy sobie, że mamy bazę danych użytkowników zarządzaną przez usługę internetową. Nasza usługa korzysta z niestandardowej hipermedii opartej na JSON, dla której przypisujemy typ MIME application / json + userdb (Może być również application / xml + userdb i application / cokolwiek + userdb - wiele typów mediów może być obsługiwanych). Klient i serwer są zaprogramowani do zrozumienia tego formatu, ale nie wiedzą o sobie nawzajem. Tak jak Roy Fielding zwraca uwagę:

Interfejs API REST powinien poświęcić prawie cały swój wysiłek opisowy w   definiowanie rodzaju (-ów) mediów używanych do reprezentowania zasobów i prowadzenia   stan aplikacji lub definiowanie nazw rozszerzonych relacji i / lub   hipertekstowy znacznik dla istniejących standardowych typów mediów.

Żądanie podstawowego zasobu / może zwrócić coś takiego:

Żądanie

GET /
Accept: application/json+userdb

Odpowiedź

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Z opisu naszych mediów wiemy, że możemy znaleźć informacje o powiązanych zasobach z sekcji zwanych "linkami". To się nazywa Kontrola hipermedii. W takim przypadku z takiej sekcji możemy stwierdzić, że możemy znaleźć listę użytkowników, wysyłając kolejną prośbę /user:

Żądanie

GET /user
Accept: application/json+userdb

Odpowiedź

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Wiele możemy powiedzieć na podstawie tej odpowiedzi. Na przykład teraz wiemy, że możemy utworzyć nowego użytkownika poprzez POSTing do /user:

Żądanie

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

Odpowiedź

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Wiemy również, że możemy zmienić istniejące dane:

Żądanie

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

Odpowiedź

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Zauważ, że używamy różnych czasowników HTTP (GET, PUT, POST, DELETE itd.) Do manipulowania tymi zasobami, a jedyną wiedzą, którą zakładamy na temat klientów, jest nasza definicja mediów.

Dalsze czytanie:

(Ta odpowiedź była przedmiotem dużej krytyki za pominięcie tej kwestii, w większości była to uczciwa krytyka: to, co pierwotnie opisałem, było bardziej zgodne z tym, jak REST był zwykle wdrażany kilka lat temu, kiedy Najpierw napisałem to, a nie jego prawdziwe znaczenie. Zrewidowałem odpowiedź, aby lepiej przedstawić prawdziwe znaczenie.)


2788
2018-03-22 19:37



Nie. REST nie pojawił się jako kolejne słowo modowe. Stało się to środkiem opisującym alternatywę dla wymiany danych opartej na SOAP. Termin REST pomaga sformułować dyskusję na temat transferu i dostępu do danych. - tvanfosson
Niemniej jednak sercem REST (w praktycznym zastosowaniu) jest "nie używaj GET do wprowadzania zmian, używaj POST / PUT / DELETE", co jest radą, którą słyszałem (i śledzę) od dawna, zanim pojawiło się SOAP. ODPOCZYNEK ma zawsze tam był, aż do niedawna nie zyskał nazwy poza "sposobem na zrobienie tego". - Dave Sherohman
Nie zapomnij o "Hypertext jako silniku stanu aplikacji". - Hank Gay
Ta odpowiedź nie trafia w sedno. HTTP jest rzadko wspominany w pracy magisterskiej Fieldinga. - user359996
Ta odpowiedź nie wspomina o celu REST i sprawia, że ​​wygląda na to, że chodzi wyłącznie o czyste identyfikatory URI. Chociaż może to być popularne postrzeganie REST, odpowiedzi D. Shawleya i OLUIE są bardziej dokładne - chodzi o to, aby móc korzystać z funkcji wbudowanych w architekturę, takich jak buforowanie, pracując z nim zamiast przeciwnie. Ulepszone identyfikatory URI są najczęściej powszechnym efektem ubocznym. - T.R.


Programowanie RESTful dotyczy:

  • zasoby są identyfikowane przez trwały identyfikator: URI są wszechobecnym wyborem identyfikatorów w tych dniach
  • zasoby są manipulowane przy użyciu wspólnego zestawu czasowników: powszechnie znane są metody HTTP - czcigodny Create, Retrieve, Update, Delete staje się POST, GET, PUT, i DELETE. Ale REST nie ogranicza się do HTTP, jest to obecnie najczęściej używany transport.
  • faktyczna reprezentacja pobierana dla zasobu zależy od żądania, a nie od identyfikatora: użyj nagłówków Accept, aby kontrolować, czy chcesz XML, HTTP, czy nawet obiekt Java reprezentujący zasoby
  • utrzymywanie stanu w obiekcie i reprezentowanie stanu w reprezentacji
  • reprezentowanie relacji między zasobami w reprezentacji zasobu: powiązania między obiektami są osadzone bezpośrednio w reprezentacji
  • reprezentacje zasobów opisują, w jaki sposób można używać reprezentacji iw jakich okolicznościach powinien być odrzucany / ponownie zapisywany w spójny sposób: użycie nagłówków HTTP Cache-Control

Ten ostatni jest prawdopodobnie najważniejszy pod względem konsekwencji i ogólnej skuteczności REST. Ogólnie rzecz biorąc, większość dyskusji RESTful koncentruje się na HTTP i jego wykorzystaniu z przeglądarki, a co nie. Rozumiem, że R. Fielding ukuł termin, kiedy opisał architekturę i decyzje prowadzące do HTTP. Jego praca magisterska dotyczy architektury i pamięci podręcznej zasobów, a nie HTTP.

Jeśli naprawdę interesuje Cię architektura REST i dlaczego działa, przeczytaj jego tezy kilka razy i przeczytaj Cała sprawa nie tylko rozdział 5! Następnie spójrz na dlaczego DNS działa. Przeczytaj o hierarchicznej organizacji DNS i o tym, jak działają odesłania. Następnie przeczytaj i zastanów się, jak działa buforowanie DNS. Na koniec przeczytaj specyfikacje HTTP (RFC2616 i RFC3040 w szczególności) i zastanowić się, jak i dlaczego buforowanie działa w taki sposób, w jaki działa. W końcu po prostu kliknie. Ostatnim objawieniem dla mnie było, gdy zobaczyłem podobieństwo między DNS i HTTP. Następnie zrozumienie, dlaczego interfejsy SOA i Message Passing Interfaces są skalowalne, zaczyna klikać.

Myślę, że najważniejszą sztuczką do zrozumienia znaczenia architektury i wydajności RESTful i Udostępniane nic architektury to unikanie rozłączania się z technologią i szczegółami implementacji. Skoncentruj się na tym, kto jest właścicielem zasobów, kto jest odpowiedzialny za ich tworzenie / utrzymywanie itd. Następnie pomyśl o reprezentacjach, protokołach i technologiach.


500
2017-07-04 05:47



Odpowiedź dostarczająca listę czytelniczą jest bardzo odpowiednia dla tego pytania. - ellisbben
Dziękuję za aktualizację. PUT i POST tak naprawdę nie mapuj jeden na jeden z aktualizacją i tworzeniem. PUT może być użyty do utworzenia, jeśli klient dyktuje, jaki będzie identyfikator URI. POST tworzy, jeśli serwer przypisuje nowy URI. - D.Shawley
Nie zapomnij o PATCHU. - epitka
URN to identyfikator URI korzystający z urn: schemat. Koncepcyjnie nie ma różnicy; jednak URN wymaga osobno zdefiniowanej metody "zlokalizowania" zasobu zidentyfikowanego (nazwanego) przez URN. Należy zwrócić uwagę, aby nie wprowadzać niejawnego sprzężenia podczas określania nazwanych zasobów i ich lokalizacji. - D.Shawley
@ellisbben Uzgodnione. Jeśli dobrze rozumiem, jest to rozprawa, która doprowadziła do REST: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm - Philip Couling


Tak może wyglądać.

Utwórz użytkownika z trzema właściwościami:

POST /user
fname=John&lname=Doe&age=25

Serwer odpowiada:

200 OK
Location: /user/123

W przyszłości możesz pobrać informacje o użytkowniku:

GET /user/123

Serwer odpowiada:

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

Aby zmodyfikować rekord (lname i age pozostanie niezmieniony):

PATCH /user/123
fname=Johnny

Aby zaktualizować rekord (i konsekwentnie lname i age będzie NULL):

PUT /user/123
fname=Johnny

392
2017-11-18 20:46



Dla mnie ta odpowiedź uchwyciła istotę pożądanej odpowiedzi. Prosty i pragmatyczny. Oczywiście istnieje wiele innych kryteriów, ale podany przykład to świetna platforma startowa. - CyberFonic
W ostatnim przykładzie używa @pbreitenbach PUT fname=Jonny. To by się ustawiło lname i age do wartości domyślnych (prawdopodobnie NULL lub pusty łańcuch i liczba całkowita 0), ponieważ a PUT  zastępuje cały zasób z danymi z przedstawionej reprezentacji. To nie jest to, co sugeruje "aktualizacja", zrobić prawdziwą aktualizację, użyj PATCH metoda ponieważ nie zmienia to pól, które nie są określone w reprezentacji. - Nicholas Shanks
Nicholas ma rację. Ponadto identyfikator URI dla pierwszego testu POST, który tworzy użytkownika, powinien być nazywany użytkownikiem, ponieważ /user/1 nie ma sensu i powinien tam być wpis /users. Odpowiedź powinna być 201 Created i nie tylko w tym przypadku. - DanMan
Nicholas i Danman mają rację. Ta odpowiedź jest zwięzła, ale ma kilka wad. - leslie.zhang
To tylko przykład API niekoniecznie interfejsu API REST. Usługa RESTful ma ograniczenia, których przestrzega. Architektura klient-serwer, bezstanowość, pamięć podręczna, system warstwowy, jednolity interfejs. - Radmation


Świetna książka o REST REST w praktyce.

Trzeba przeczytać Reprezentacyjny transfer państw (REST) i Interfejsy REST API muszą być oparte na hipertekstach 

Zobacz artykuł Martina Fowlersa Model dojrzałości Richardsona (RMM) dla wyjaśnienia, czym jest usługa REST.

Richardson Maturity Model

Aby być WYRAŻONYM, usługa musi spełniać warunki Hypermedia jako silnik stanu aplikacji. (HATEOAS)to znaczy, że musi osiągnąć poziom 3 w RMM, Przeczytaj artykuł dla szczegółów lub slajdy z rozmowy qcon.

Ograniczenie HATEOAS jest akronimem   dla Hypermedia jako silnika   Stan aplikacji. Ta zasada jest   kluczowy wyróżnik między REST   i większość innych form serwera klienta   system.

...

Klient wymagający aplikacji RESTful   zna tylko jeden stały adres URL, do którego można uzyskać dostęp   to. Wszystkie przyszłe działania powinny być   wykrywalny dynamicznie z   linki hipermedialne zawarte w   reprezentacje zasobów, które   są zwracane z tego adresu URL.   Występują również standardowe typy mediów   powinien być zrozumiany przez każdego   klient, który może używać RESTful API.   (Z Wikipedii, wolnej encyklopedii)

REST Lakmus test dla ram WWW jest podobnym testem dojrzałości dla frameworków internetowych.

Zbliżanie się do czystej REST: Nauka kochania HATEOAS to dobry zbiór linków.

REST a SOAP dla Public Cloud omawia bieżące poziomy użycia REST.

REST i wersjonowanie omawia Extensibility, Versioning, Evolvability itp.  poprzez Modifiability


170
2018-03-22 15:20



Myślę, że ta odpowiedź dotyka kluczowego punktu zrozumienia REST: co oznacza słowo reprezentacyjny oznaczać. Poziom 1 - Zasoby mówią o stan. Poziom 2 - Mówi o HTTP Verbs transfer (czytać zmiana). Poziom 3 - HATEOAS mówi o przeniesieniu przyszłych transferów za pośrednictwem reprezentacji (zwrócono JSON / XML / HTML), co oznacza, że ​​wiesz, jak powiedzieć następną rundę rozmowy z zwróconymi informacjami. Tak więc REST czyta: "(reprezentacyjne (transfer stanu))", zamiast "(transfer stanu reprezentacji)". - lcn
Różnica między REST a POX - nobar


Czym jest REST?

REST oznacza Reprezentacyjny transfer państwa. (To jest czasami   ortograficzne "ReST".) To opiera się na bezpaństwowcu, kliencie-serwerze, pamięci podręcznej   protokół komunikacyjny - i praktycznie we wszystkich przypadkach HTTP   używany jest protokół.

REST jest stylem architektury do projektowania aplikacji sieciowych.   Chodzi o to, że zamiast używać złożonych mechanizmów, takich jak CORBA,   RPC lub SOAP do łączenia się między maszynami, do tworzenia służy prosty HTTP   połączenia między maszynami.

Pod wieloma względami można przeglądać samą sieć WWW opartą na HTTP   jako architektura oparta na REST. Aplikacje RESTful używają żądań HTTP   publikować dane (tworzyć i / lub aktualizować), odczytywać dane (np. tworzyć zapytania),   i usuń dane. Tak więc REST wykorzystuje HTTP dla wszystkich czterech CRUD   (Twórz / Odczyt / Aktualizuj / Usuń) operacje.

REST jest lekką alternatywą dla mechanizmów takich jak RPC (Remote   Połączenia procedur) i usług sieci Web (SOAP, WSDL i inni). Później, będziemy   zobacz, jak bardzo prosty jest REST.

Pomimo prostoty, REST jest w pełni funkcjonalny; jest w zasadzie   nic, co możesz zrobić w usługach sieciowych, czego nie można zrobić przy pomocy usługi RESTful   architektura. REST nie jest "standardem". Nigdy nie będzie W3C   zalecenie dotyczące REST, na przykład. I chociaż istnieje REST   programowanie, praca z REST jest tak prosta, że ​​możesz   często "zwijaj własne" dzięki standardowym funkcjom biblioteki w językach takich jak   Perl, Java lub C #.

Jedno z najlepszych odniesień, które znalazłem, gdy próbuję znaleźć proste prawdziwe znaczenie odpoczynku.

http://rest.elkstein.org/


128
2018-03-22 14:53





REST wykorzystuje różne metody HTTP (głównie GET / PUT / DELETE) do manipulowania danymi.

Zamiast używać konkretnego adresu URL do usunięcia metody (np. /user/123/delete), wysłałbyś żądanie DELETE do /user/[id] URL, aby edytować użytkownika, aby pobrać informacje o użytkowniku, któremu wysłano żądanie GET /user/[id]

Na przykład zamiast zestawu adresów URL, które mogą wyglądać jak niektóre z poniższych.

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

Używasz "czasowników" HTTP i masz ...

GET /user/2
DELETE /user/2
PUT /user

85
2017-07-12 16:33



To jest "używanie HTTP poprawnie", co nie jest tym samym, co "restful" (chociaż jest z nim powiązane) - Julian Reschke
Możesz także użyć / user / del / 2 i / user / remove / 2 lub ... GET / DELETE / PUT / POST to tylko standardowy, "właściwy" sposób na zrobienie takich rzeczy (a jak mówi Julian, to nie wszystko jest REST) - dbr
Jasne, ale nie ma powodu, aby ich unikać. REST po prostu oszczędza za każdym razem wymyślanie koła. Jeśli chodzi o API, REST jest świetny (spójność!), Ale dla struktury losowej strony internetowej nie ma znaczenia, że ​​powiedziałbym (może to być więcej kłopotu niż jest warte) - dbr
Vadim, to byłby po prostu RPC. Niebezpiecznie jest też używać GET do modyfikowania danych, ponieważ (między innymi) wyszukiwarka może spiderować twoje linki do usuwania i odwiedzić je wszystkie. - aehlke
@aehlke - Myślę, że prawdziwe pytanie brzmiałoby: "Dlaczego anonimowy użytkownik ma możliwość usuwania zapisów z twojego systemu?" - Spencer Ruport