Mówiąc najprościej, robisz to całkowicie wstecz.

Nie powinieneś podchodzić do tego z tego, jakich adresów URL powinieneś używać. Adresy URL będą skutecznie dostarczane "za darmo", gdy już zdecydujesz, jakie zasoby są niezbędne dla Twojego systemu i jak będziesz je reprezentować, a także interakcje między zasobami a stanem aplikacji.

Cytuję Roy Fielding

REST API powinien wydać prawie wszystkie jego opisowy wysiłek w definiowanie Typ (- Y) nośnika (- ów) używany (- ych) do reprezentowania zasoby i aplikacja kierowcy stan, lub w definiowaniu rozszerzonych nazwy relacji i / lub hipertekst-enabled mark-up for existing standardowe typy nośników. Każdy wysiłek spędzony opisujące jakie metody stosować na czym Interesujące adresy uri powinny być w całości określone w zakresie reguły przetwarzania dla typu nośnika (a w większości przypadków już zdefiniowane przez istniejące typy nośników). [Awaria tutaj oznacza to, że poza pasmem informacje na zamiast hipertekstu.]

Ludzie zawsze zaczynają od Uri i myślą, że jest to rozwiązanie, a potem mają tendencję do pominięcia kluczowej koncepcji w architekturze REST, w szczególności, jak zacytowano powyżej, " awaria oznacza tutaj, że informacje spoza pasma napędzają interakcję zamiast hipertekstu."

Szczerze mówiąc, wielu widzi kilka Uri, a niektórzy dostają, wstawiają i publikują i myślą, że odpoczynek jest łatwy. Odpoczynek nie jest łatwy. RPC przez HTTP jest łatwe, przenoszenie blobów danych z powrotem i forth proxied przez HTTP payloads jest łatwe. Odpoczynek jednak wykracza poza to. Reszta to protokół agnostyczny. HTTP jest po prostu bardzo popularny i odpowiedni dla Systemów REST.

REST żyje w typach mediów, ich definicjach i sposobie, w jaki aplikacja napędza działania dostępne dla tych zasobów za pomocą hipertekstu (linki, efektywnie).

Istnieją różne poglądy na temat typów mediów w systemach REST. Niektóre preferują obciążenia specyficzne dla aplikacji, podczas gdy inne lubią podnosić istniejące typy nośników do role, które są odpowiednie dla aplikacji. Na przykład, z jednej strony masz określone schematy XML zaprojektowane dla Twojej aplikacji, a nie używając czegoś takiego jak XHTML jako reprezentacji, być może poprzez mikroformaty i inne mechanizmy.

Oba podejścia mają swoje miejsce, myślę, że XHTML działa bardzo dobrze w scenariuszach, które nakładają się zarówno na human driven, jak i machine driven web, podczas gdy pierwsze, bardziej szczegółowe typy danych czuję, że lepiej ułatwiają maszynę do maszyny interakcje. Uważam, że podnoszenie formatów towarów może potencjalnie utrudnić negocjacje treści. "application / xml + yourresource" jest o wiele bardziej specyficzny jako typ nośnika niż "application / xhtml+xml", ponieważ ten ostatni może odnosić się do wielu ładunków, które mogą lub nie mogą być czymś, co klient maszyny jest rzeczywiście zainteresowany, ani nie może określić bez introspekcji.

Jednak XHTML działa bardzo dobrze (oczywiście) w ludzkiej sieci, gdzie przeglądarki internetowe i rendering są bardzo ważne.

Twoja aplikacja poprowadzi cię w tego rodzaju decyzjach.

Częścią procesu projektowania systemu REST jest odkrywanie zasobów pierwszej klasy w systemie, wraz z pochodnymi, zasobami wsparcia niezbędnymi do wspierania operacji na zasobach podstawowych. Gdy zasoby zostaną odkryte, następnie reprezentacja tych zasobów, a także diagramy stanu pokazujące przepływ zasobów przez hipertekst w reprezentacjach, ponieważ następny wyzwanie.

Przypomnijmy, że każda reprezentacja zasobu, w systemie hipertekstowym, łączy zarówno rzeczywistą reprezentację zasobu, jak i przejścia stanu dostępne dla zasobu. Traktuj każdy zasób jako węzeł na wykresie, a łącza są liniami odchodzącymi od tego węzła do innych stanów. Linki te informują klientów nie tylko o tym, co można zrobić, ale co jest wymagane do ich wykonania (ponieważ dobry link łączy URI i wymagany typ nośnika).

Na przykład, możesz mieć:

<link href="http://example.com/users" rel="users" type="application/xml+usercollection"/>
<link href="http://example.com/users?search" rel="search" type="application/xml+usersearchcriteria"/>

Twoja dokumentacja będzie mówić o polu rel o nazwie "users" i typie nośnika "application / xml+youruser".

Te linki mogą wydawać się zbędne, wszystkie mówią do tego samego URI, w zasadzie. Ale nie są.

Dzieje się tak dlatego, że dla relacji "users" link mówi o kolekcji użytkowników i możesz użyć jednolitego interfejsu do pracy z kolekcją (GET to retrieve all of them, DELETE to delete all of them, itd.)

Jeśli piszesz na ten adres URL, będziesz musiał przekazać dokument "application / xml + usercollection", który prawdopodobnie będzie zawierał tylko jedną instancję użytkownika w dokumencie, więc możesz dodać użytkownika, lub nie, być może, aby dodać kilka na raz. Być może Twoja dokumentacja zasugeruje, że możesz po prostu przekazać pojedynczy typ użytkownika, zamiast kolekcji.

Możesz zobaczyć, czego aplikacja wymaga, aby przeprowadzić wyszukiwanie, zgodnie z linkiem "Szukaj" i jest to mediatype. Dokumentacja dla typu mediów wyszukiwania powie Ci, jak to się zachowuje i czego możesz się spodziewać jako wyników.

Klient musi wiedzieć, jak manipulować i interpretować typy mediów, ale nie musi dbać o to, gdzie to jest idzie.

Te dwa linki są semantycznie identyczne w oczach klienta:

<link href="http://example.com/users?search" rel="search" type="application/xml+usersearchcriteria"/>
<link href="http://example.com/AW163FH87SGV" rel="search" type="application/xml+usersearchcriteria"/>

Re 1 : na razie wygląda to dobrze. Pamiętaj, aby zwrócić URI nowo utworzonego użytkownika w nagłówku "Location:" jako część odpowiedzi na POST, wraz z kodem stanu "201 Created".

Re 2 : aktywacja przez GET to zły pomysł, a włączenie czasownika w URI to zapach projektu. Warto rozważyć zwrócenie formularza NA GET. W aplikacji internetowej byłby to formularz HTML z przyciskiem Wyślij; w przypadku użycia API możesz chcieć zwrócić reprezentację, która zawiera URI do umieszczenia w celu aktywacji konta. Oczywiście możesz również umieścić ten URI w odpowiedzi na POST do / users. Użycie PUT zapewni, że twoje żądanie będzie idempotentne, tzn. może zostać bezpiecznie wysłane ponownie, jeśli klient nie jest pewien sukcesu. Ogólnie rzecz biorąc, zastanów się, w jakie zasoby możesz przekształcić swoje czasowniki (rodzaj "nounification of verbs"). Zadaj sobie pytanie, z jaką metodą Twoje konkretne działanie jest najbardziej dopasowane. Np. change_password - > PUT; deactivate - > probably DELETE; add_credit - >ewentualnie POST lub PUT. Wskaż Klientowi odpowiednie Uri, włączając je do swoich oświadczeń.

Re 3.Nie wymyślaj nowych kodów statusu, chyba że uważasz, że są tak ogólne, że zasługują na standaryzację globalną. Postaraj się użyć najbardziej odpowiedniego dostępnego kodu statusu (przeczytaj o nich wszystkie w RFC 2616). Dołącz dodatkowe informacje do organu odpowiedzi. Jeśli naprawdę, naprawdę jesteś pewien, że chcesz wymyślić nowy kod statusu, pomyśl jeszcze raz; jeśli nadal wierzysz upewnij się więc, że przynajmniej wybierzesz odpowiednią kategorię (1XX -> OK, 2XX -> informacja, 3xx-> przekierowanie; 4xx -> błąd klienta, 5xx - > błąd serwera). Czy wspominałem, że wymyślanie nowych kodów statusu to zły pomysł?

Re 4. jeśli w jakikolwiek sposób jest to możliwe, użyj frameworka uwierzytelniania wbudowanego w HTTP. Sprawdź, jak Google robi uwierzytelnianie w GData. Ogólnie rzecz biorąc, nie umieszczaj kluczy API w swoich Uri. Staraj się unikać sesji w celu zwiększenia skalowalności i obsługi buforowania-jeśli odpowiedź na żądanie różni się ze względu na coś, co zdarzyło się wcześniej, zwykle przywiązałeś się do konkretnej instancji procesu serwera. Znacznie lepiej jest zmienić stan sesji w stan klienta (np. uczynić go częścią kolejnych żądań) lub uczynić go jawnym, zamieniając go w stan zasobów (serwera), tzn. nadając mu własny URI.

1. masz dobry pomysł, jak zaprojektować swoje zasoby, IMHO. Niczego bym nie zmienił.

2. zamiast próbować rozszerzyć HTTP o więcej czasowników, zastanów się, do czego można zredukować proponowane czasowniki pod względem podstawowych metod i zasobów HTTP. Na przykład, zamiast czasownika activate_login, możesz ustawić zasoby takie jak: /api/users/1/login/active, który jest prostym logicznym. Aby aktywować login, po prostu PUT dokument tam, który mówi "prawda" lub 1 lub cokolwiek. Na deaktywacja PUT dokumentu, który jest pusty lub mówi 0 lub false.

Podobnie, aby zmienić lub ustawić hasła, po prostu wykonaj PUT S do /api/users/1/password.

Gdy potrzebujesz dodać coś (na przykład kredyt), pomyśl w kategoriach POST s. na przykład, możesz zrobić {[7] } do zasobu takiego jak /api/users/1/credits z ciałem zawierającym liczbę kredytów do dodania. A PUT na tym samym zasobie może być użyty do nadpisania wartości zamiast dodawania. A POST z liczbą ujemną w ciele odjęłaby, a więc on

3.Zdecydowanie odradzam Rozszerzanie podstawowych kodów statusu HTTP. Jeśli nie możesz znaleźć takiego, który dokładnie pasuje do twojej sytuacji, wybierz najbliższą i umieść szczegóły błędu w treści odpowiedzi. Pamiętaj również, że nagłówki HTTP są rozszerzalne; aplikacja może zdefiniować wszystkie niestandardowe nagłówki, które lubisz. Na przykład jedna aplikacja, nad którą pracowałem, może zwrócić 404 Not Found w wielu okolicznościach. Zamiast zmuszać klienta do analizowania ciała odpowiedzi dla dlatego właśnie dodaliśmy nowy nagłówek X-Status-Extended, który zawierał nasze rozszerzenia kodu statusowego. Więc możesz zobaczyć odpowiedź w stylu:

HTTP/1.1 404 Not Found    
X-Status-Extended: 404.3 More Specific Error Here

W ten sposób klient HTTP, taki jak przeglądarka internetowa, nadal będzie wiedział, co zrobić ze zwykłym kodem 404, a bardziej wyrafinowany klient HTTP może wybrać nagłówek X-Status-Extended w celu uzyskania bardziej szczegółowych informacji.

4. do uwierzytelniania, polecam korzystanie z uwierzytelniania HTTP, jeśli możesz. Ale IMHO nie ma nic złego w korzystanie z uwierzytelniania opartego na plikach cookie, jeśli jest to dla ciebie łatwiejsze.

Podstawy odpoczynku

REST ma jednorodne ograniczenie interfejsu, które mówi, że klient REST musi polegać na standardach zamiast na specyficznych dla aplikacji szczegółach rzeczywistej usługi REST, więc klient REST nie złamie się przez drobne zmiany i prawdopodobnie będzie wielokrotnego użytku.

Jest więc umowa między Klientem REST a usługą REST. Jeśli używasz HTTP jako protokołu bazowego, następujące standardy są częścią Umowy:

• HTTP 1.1
  • definicje metod
  • definicje kodów statusu
  • cache control headers
  • nagłówki accept i content-type
  • nagłówki auth
• IRI (utf8 URI )
• body (wybierz jeden)
  • zarejestrowany typ MIME specyficzny dla aplikacji, np. maze+xml
  • typ MIME specyficzny dla dostawcy, np. vnd.github+json
  • ogólny typ MIME z
    • specyficzne dla aplikacji słownictwo RDF, np. ld+json & hydra, schema.org
    • profil specyficzny dla aplikacji, np. hal+json & profil link param (chyba)
• hiperłącza
  • co powinno je zawierać (wybierz jeden)
    • wysyłanie nagłówków linków
    • wysyłanie odpowiedzi hipermedialnej, np. html, atom+xml, hal + json, ld+json&hydra, itp...
  • semantyka
    • użyj relacji IANA link i prawdopodobnie niestandardowe link relations
    • użyj specyficznego dla aplikacji słownictwa RDF

REST ma ograniczenie bezpaństwowe, które deklaruje, że komunikacja między usługą REST a klientem musi być bezpaństwowa. Oznacza to, że usługa REST nie może utrzymywać Stanów klienta, więc nie można mieć magazynu sesji po stronie serwera. Musisz uwierzytelnić każde żądanie. Więc na przykład HTTP basic auth (część standardu HTTP) jest w porządku, ponieważ wysyła nazwę użytkownika i hasło przy każdym żądaniu.

Aby odpowiedzieć na pytania

1. Tak, może być.

   Dla przypomnienia, klienci nie dbają o strukturę IRI, dbają o semantykę, ponieważ podążają za linkami o relacjach z linkami lub atrybutach linked data (RDF).

   Jedyną ważną rzeczą w tęczówce jest to, że pojedynczy IRI musi zidentyfikować tylko jeden zasób. Dozwolone jest, aby jeden zasób, podobnie jak użytkownik, miał wiele różnych przesłon.

   It to dość proste, dlaczego używamy nice IRIs jak /users/123/password; o wiele łatwiej jest napisać logikę routingu na serwerze, gdy rozumiesz IRI po prostu czytając go.

2. Masz więcej czasowników, takich jak PUT, PATCH, OPTIONS, a nawet więcej, ale nie potrzebujesz ich więcej... Zamiast dodawać nowe czasowniki musisz nauczyć się jak dodawać nowe zasoby.

   activate_login -> PUT /login/active true deactivate_login -> PUT /login/active false change_password -> PUT /user/xy/password "newpass" add_credit -> POST /credit/raise {details: {}}

   (logowanie nie ma sensu z perspektywy REST, ze względu na ograniczenie stateless.)

3. Twój użytkownicy nie dbają o to, dlaczego problem istnieje. Chcą wiedzieć tylko, czy jest sukces lub błąd, i prawdopodobnie komunikat o błędzie, który mogą zrozumieć, na przykład: "Przepraszam, ale nie byliśmy w stanie zapisać swój post.", itp...

   Nagłówki statusu HTTP są standardowymi nagłówkami. Wszystko inne powinno być w ciele. Pojedynczy nagłówek nie wystarczy do opisania np. szczegółowych wielojęzycznych komunikatów o błędach.

4. The stateless constraint (wraz z cache i warstwowe ograniczenia systemu) zapewnia, że usługa skaluje się dobrze. Na pewno nie chcesz utrzymywać milionów sesji na serwerze, kiedy możesz zrobić to samo na klientach...

   Klient zewnętrzny otrzymuje token dostępu, jeśli użytkownik udzieli mu dostępu za pomocą głównego klienta. Następnie klient zewnętrzny wysyła token dostępu do każdego żądania. Istnieją bardziej skomplikowane rozwiązania, na przykład można podpisać każde pojedyncze żądanie itp. Aby uzyskać więcej informacji, sprawdź OAuth Instrukcja obsługi.

Literatura pokrewna

• [122]}style architektoniczne i projektowanie sieciowych Architektur oprogramowania
  W 2011 roku został wybrany do Izby Gmin.]} 2000, University of California, Irvine
• [128]} interfejsy API trzeciej generacji-wypełnianie luki między REST a połączonymi danymi
  W 2011 roku, po raz pierwszy w historii, został wybrany do Izby Reprezentantów.]} 2014, Politechnika Grazu, Austria

Dla podanych przez Ciebie przykładów użyłbym następującego:

Activate_login

POST /users/1/activation

Deactivate_login

DELETE /users/1/activation

Change_password

PUT /passwords (zakłada się, że użytkownik jest uwierzytelniony)

Add_credit

POST /credits (zakłada się, że użytkownik jest uwierzytelniony)

W przypadku błędów zwrócisz błąd w treści w formacie, w którym otrzymałeś żądanie, więc jeśli otrzymasz:

DELETE /users/1.xml

Wyślesz odpowiedź z powrotem w XML, to samo dotyczy JSON itp...

Do uwierzytelniania należy użyć uwierzytelniania http.

1. Użyj post, gdy nie wiesz, jak będzie wyglądał nowy Uri zasobu (tworzysz nowego użytkownika, aplikacja przypisze nowy użytkownik to id), PUT do aktualizacji lub tworzenia zasobów, które wiesz, jak mają być reprezentowane (przykład: PUT /myfiles/thisismynewfile.txt)
2. zwraca opis błędu w treści wiadomości
3. można użyć uwierzytelniania HTTP (jeśli wystarczy) Usługi internetowe powinny być stateles

Sugerowałbym (jako pierwsze przejście), że PUT powinny być używane tylko do aktualizacji istniejących podmiotów. POST powinny być używane do tworzenia nowych. tj.

/api/users     when called with PUT, creates user record

Verbose, ale skopiowane ze specyfikacji metody HTTP 1.1 w http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.3 GET

Metoda GET oznacza pobieranie wszelkich informacji (w postaci encji) zidentyfikowanych przez Request-URI. Jeśli Request-URI odnosi się do procesu produkującego dane, to wytworzone dane są zwracane jako jednostka w odpowiedzi, a nie tekst źródłowy procesu, chyba że tekst ten jest wynikiem proces.

Semantyka metody GET zmienia się na" warunkowy GET", jeśli wiadomość żądania zawiera pole nagłówka If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match lub If-Range. Warunkowa metoda GET wymaga, aby jednostka została przeniesiona tylko w okolicznościach opisanych w warunkowych polach nagłówka. Warunkowa metoda GET ma na celu zmniejszenie niepotrzebnego wykorzystania sieci poprzez umożliwienie odświeżania buforowanych jednostek bez konieczności wielokrotnego żądania lub przekazywania danych już przechowywanych przez Klienta.

Semantyka metody GET zmienia się na" częściowe GET", jeśli wiadomość żądania zawiera pole nagłówka zakresu. Część GET żąda przeniesienia tylko części podmiotu, jak opisano w sekcji 14.35. Metoda partial GET ma na celu zmniejszenie niepotrzebnego wykorzystania sieci poprzez umożliwienie częściowo pobranych jednostek bez przesyłania danych już przechowywanych przez Klienta.

ODPOWIEDŹ na GET żądanie jest buforowalne wtedy i tylko wtedy, gdy spełnia wymagania dotyczące buforowania HTTP opisane w Sekcji 13.

Patrz sekcja 15.1.3 ze względów bezpieczeństwa w przypadku stosowania formularzy.

9.5 POST

Metoda POST jest używana do żądania, aby serwer origin zaakceptował encję zamkniętą w żądaniu jako nowy subductive zasobu identyfikowanego przez Request-URI w linii żądania. POST został zaprojektowany tak, aby umożliwić jednolitą metodę pokrycia następujących funkcje:

  - Annotation of existing resources;
  - Posting a message to a bulletin board, newsgroup, mailing list,
    or similar group of articles;
  - Providing a block of data, such as the result of submitting a
    form, to a data-handling process;
  - Extending a database through an append operation.

Rzeczywista funkcja wykonywana przez metodę POST jest określona przez serwer i zwykle zależy od Request-URI. Opublikowany podmiot jest podporządkowany temu URI w taki sam sposób, jak plik jest podporządkowany katalogowi, który go zawiera, artykuł newsowy jest podporządkowany grupie dyskusyjnej, do której jest wysłany, lub rekord jest podporządkowany bazie danych.

Akcja wykonana metodą POST może nie spowodować powstania zasobu, który można zidentyfikować za pomocą URI. W w tym przypadku 200 (OK) lub 204 (Brak treści) jest odpowiednim statusem odpowiedzi, w zależności od tego, czy odpowiedź zawiera podmiot opisujący wynik.

Jeśli zasób został utworzony na serwerze origin, odpowiedź powinna wynosić 201 (Created) i zawierać encję opisującą status żądania i odnoszącą się do nowego zasobu oraz nagłówek lokalizacji (patrz sekcja 14.30).

Odpowiedzi na tę metodę nie są buforowalne, chyba że odpowiedź zawiera odpowiednie pola nagłówka Cache-Control lub Expires. Jednak odpowiedź 303 (Zobacz inne) może być użyta do skierowania agenta użytkownika do pobrania zasobu z możliwością buforowania.

Żądania POST muszą spełniać wymagania dotyczące transmisji wiadomości określone w sekcji 8.2.

Zob. sekcja 15.1.3 ze względów bezpieczeństwa.

9.6 PUT

Metoda PUT wymaga, aby zamknięty podmiot był przechowywany pod dostarczonym Request-URI. Jeśli Request-URI odnosi się do już istniejącego zasobu, zamknięty podmiot powinien być uważany za zmodyfikowaną wersję tego, który znajduje się na serwerze origin. Jeśli Request-URI nie wskazuje na istniejący zasób, a ten URI może być zdefiniowany jako nowy zasób przez żądającego agenta użytkownika, serwer źródłowy może utworzyć zasób z tym URI. Jeśli zostanie utworzony nowy zasób, serwer źródłowy musi poinformować agenta użytkownika za pomocą odpowiedzi 201 (Created). Jeśli istniejący zasób jest modyfikowany, albo 200 (OK) lub 204 (Brak zawartości) kody odpowiedzi powinny być wysyłane w celu wskazania pomyślnego zakończenia wniosku. Jeśli zasób nie mógł zostać utworzony lub zmodyfikowany za pomocą Request-URI, należy udzielić odpowiedniej odpowiedzi na błąd, która odzwierciedla naturę problemu. Odbiorca encji nie może ignorować nagłówków Content-* (np. content-Range), których nie rozumie ani nie implementuje i w takich przypadkach musi zwrócić odpowiedź 501 (Nie zaimplementowaną).

Jeśli żądanie przechodzi przez cache I Request-URI identyfikuje jeden lub więcej aktualnie buforowanych podmiotów, wpisy te powinny być traktowane jako przestarzałe. Odpowiedzi na tę metodę nie są buforowalne.

Zasadnicza różnica między żądaniami POST I PUT znajduje odzwierciedlenie w innym znaczeniu Request-URI. URI w żądaniu POST identyfikuje zasób, który będzie obsługiwał zamknięty podmiot. Zasób ten może być procesem akceptującym dane, bramą do innego protokołu lub oddzielnym podmiotem akceptującym adnotacje. In contrast, URI w żądaniu PUT identyfikuje podmiot załączony do żądania-agent użytkownika wie, jaki URI jest przeznaczony, a serwer nie może próbować zastosować żądania do innego zasobu. Jeśli serwer chce, aby żądanie zostało zastosowane do innego URI,

Musi wysłać odpowiedź 301 (przeniesiona na stałe); agent użytkownika może wtedy podjąć własną decyzję dotyczącą przekierowania żądania.

Pojedynczy zasób może być identyfikowany przez wiele różnych Uri. Na na przykład artykuł może mieć URI do identyfikacji "bieżącej wersji", który jest oddzielny od URI identyfikującego każdą konkretną wersję. W takim przypadku żądanie PUT na ogólnym URI może spowodować zdefiniowanie kilku innych Uri przez serwer źródłowy.

HTTP/1.1 nie określa, w jaki sposób Metoda PUT wpływa na stan serwera źródłowego.

Żądania PUT muszą spełniać wymagania dotyczące transmisji wiadomości określone w sekcji 8.2.

O ile nie określono inaczej dla poszczególne nagłówki encji, nagłówki encji w żądaniu PUT powinny być stosowane do zasobu utworzonego lub zmodyfikowanego przez PUT.

9.7 Usuń

Metoda DELETE wymaga, aby serwer źródłowy usunął zasób określony przez Request-URI. Ta metoda może zostać nadpisana przez interwencję człowieka (lub w inny sposób) na serwerze origin. Klientowi nie można zagwarantować, że operacja została wykonana, nawet jeśli kod statusu zwrócony z serwera origin wskazuje, że akcja została zakończona pomyślnie. Serwer nie powinien jednak wskazywać sukcesu, chyba że w momencie udzielenia odpowiedzi zamierza usunąć Zasób lub przenieść go do niedostępnej lokalizacji.

Skuteczna odpowiedź powinna wynosić 200 (OK), jeśli odpowiedź zawiera podmiot opisujący status, 202 (zaakceptowana), jeśli działanie nie zostało jeszcze wdrożone, lub 204 (Brak treści), jeśli działanie zostało wdrożone, ale odpowiedź nie obejmuje podmiotu.

Jeśli wniosek przechodzi przez pamięć podręczną, a Request-URI identyfikuje jeden lub więcej aktualnie buforowanych podmiotów, wpisy te powinny być traktowane jako przestarzałe. Odpowiedzi na tę metodę nie są buforowalne.

O kodach zwrotnych REST: jest źle mieszać kody protokołu HTTP i wyniki REST.

Widziałem jednak wiele implementacji je mieszających i wielu programistów może się ze mną nie zgodzić.

Kody zwrotne HTTP są powiązane z samym HTTP Request. Wywołanie REST jest wykonywane przy użyciu żądania protokołu transferu hipertekstowego i działa na niższym poziomie niż wywołana sama metoda REST. REST jest koncepcją / podejściem,a jego wynikiem jest biznesowy / logiczny wynik, podczas gdy kod wyniku HTTP jest transport jeden.

Na przykład zwracanie "404 Not found" podczas wywoływania /users / jest mylące, ponieważ może oznaczać:

• URI się myli (HTTP)
• nie znaleziono użytkowników (reszta)

"403 Forbidden / Access Denied" może oznaczać:

• potrzebne specjalne pozwolenie. Przeglądarki mogą sobie z tym poradzić, pytając użytkownika / hasło. (HTTP)
• błędne uprawnienia dostępu skonfigurowane na serwerze. (HTTP)
• musisz być uwierzytelniony (Reszta)

I lista może być kontynuowana z " 500 Server error "(Błąd rzuconego HTTP Apache/Nginx lub błąd ograniczenia biznesowego w REST) lub innymi błędami HTTP itp...

Z kodu, trudno zrozumieć, jaka była przyczyna awarii, awaria HTTP (transport) lub awaria REST (logiczna).

Jeśli żądanie HTTP zostało fizycznie wykonane pomyślnie, powinno zawsze zwracać kod 200, niezależnie od tego, czy rekord(y) został znaleziony, czy nie. Ponieważ zasób URI jest znaleziono i był obsługiwany przez serwer http. Tak, może zwrócić pusty zestaw. Czy jest możliwe, aby otrzymać pustą stronę internetową z 200 jako wynik http, prawda?

Zamiast tego możesz zwrócić kod HTTP 200 i po prostu JSON z pustą tablicą / obiektem, lub użyć znacznika bool result/success, aby poinformować o wykonanej operacji.

Ponadto niektórzy dostawcy Internetu mogą przechwycić Twoje żądania i zwrócić Ci kod http 404. Nie oznacza to, że Twoje dane nie zostaną znalezione, ale coś jest nie tak na poziomie transportu.

From Wiki :

[1]}w lipcu 2004 r. Brytyjski dostawca usług telekomunikacyjnych BT Group wdrożył Cleanfeed system blokowania treści, który zwraca błąd 404 do każdego żądania treści uznane przez Internet Watch za potencjalnie nielegalne Fundacja. Inni dostawcy usług internetowych zwracają błąd HTTP 403 "forbidden" w tym samym okoliczności. Praktyka stosowania fałszywych błędów 404 jako środka do ujawniono również cenzurę w Tajlandii i Tunezji. W Tunezja, gdzie cenzura była ostra przed rewolucją 2011, ludzie zdali sobie sprawę z natury fałszywych błędów 404 i stworzyli wyimaginowana postać o nazwie "Ammar 404", która reprezentuje " niewidzialne cenzor".