Kody stanu REST HTTP dla nieudanej weryfikacji lub nieprawidłowego duplikatu

Tworzę aplikację z interfejsem API opartym na REST i doszedłem do momentu, w którym określam kody stanu dla każdego żądania.

Jaki kod stanu powinienem wysłać w przypadku wniosków, które nie sprawdzają poprawności lub w przypadku, gdy żądanie próbuje dodać duplikat do mojej bazy danych?

Przejrzałem http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html, ale żaden z nich nie wydaje się odpowiedni.

Czy istnieje powszechna praktyka podczas wysyłania kodów stanu?

W przypadku niepowodzenia sprawdzania poprawności danych wejściowych: 400 Błędne żądanie + opcjonalny opis. Jest to sugerowane w książce „ RESTful Web Services ”. W przypadku podwójnego zgłoszenia: 409 Konflikt

Aktualizacja z czerwca 2014 r

Odpowiednią specyfikacją był RFC2616 , który dawał użycie 400 (Bad Request) raczej wąsko jako

Serwer nie mógł zrozumieć żądania z powodu nieprawidłowej składni

Więc to może być twierdził, że to było niewłaściwe błędów semantycznych. Ale już nie; od czerwca 2014 r. odpowiednia norma RFC 7231 , która zastępuje poprzednią RFC2616, daje szersze zastosowanie 400 (Złe żądanie) jako

serwer nie może lub nie przetworzy żądania z powodu czegoś, co jest postrzegane jako błąd klienta

• Sprawdzanie poprawności nie powiodło się: 403 Zabronione („Serwer zrozumiał żądanie, ale odmawia jego spełnienia”). Wbrew powszechnej opinii RFC2616 nie mówi „403 jest przeznaczone tylko do nieudanego uwierzytelnienia”, ale „403: Wiem, czego chcesz, ale tego nie zrobię”. Ten warunek może, ale nie musi, wynikać z uwierzytelnienia.
• Próba dodania duplikatu: 409 Konflikt („Żądanie nie mogło zostać zakończone z powodu konfliktu z bieżącym stanem zasobu.”)

Zdecydowanie powinieneś podać bardziej szczegółowe wyjaśnienie w nagłówkach odpowiedzi i / lub treści (np. Z niestandardowym nagłówkiem - X-Status-Reason: Validation failed).

Polecam kod statusu 422 „Podmiot nieprzetworzony” .

11.2 422 Podmiot nieprzetworzony

Kod statusu 422 (Unprocessable Entity) oznacza, że ​​serwer rozumie typ treści encji żądania (stąd kod statusu 415 (Unsupported Media Type) jest nieodpowiedni), a składnia encji żądania jest poprawna (a więc 400 (Bad Request ) kod stanu jest nieodpowiedni), ale nie mógł przetworzyć zawartych instrukcji. Na przykład ten warunek błędu może wystąpić, jeśli treść żądania XML zawiera dobrze sformułowane (tj. Poprawne składniowo), ale semantycznie błędne instrukcje XML.

200,300, 400, 500 są bardzo ogólne. Jeśli chcesz ogólny, 400 jest OK.

422 jest używany przez rosnącą liczbę interfejsów API, a nawet jest używany przez Railsy po wyjęciu z pudełka.

Bez względu na to, jaki kod stanu wybierzesz dla swojego interfejsu API, ktoś się nie zgodzi. Ale wolę 422, ponieważ „400 + status tekstowy” uważam za zbyt ogólny. Ponadto nie korzystasz z parsera zgodnego z JSON; przeciwnie, 422 z odpowiedzią JSON jest bardzo wyraźny i można przekazać wiele informacji o błędach.

Mówiąc o odpowiedzi JSON, mam tendencję do standaryzacji odpowiedzi na błąd Railsów w tym przypadku, która jest:

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

Ten format jest idealny do sprawdzania poprawności formularza, który uważam za najbardziej skomplikowany przypadek do obsługi pod względem „bogactwa raportowania błędów”. Jeśli twoja struktura błędów jest taka, prawdopodobnie obsłuży wszystkie potrzeby związane z raportowaniem błędów.

200

Ugh ... (309, 400, 403, 409, 415, 422) ... wiele odpowiedzi próbuje zgadnąć, argumentować i ustandaryzować najlepszy kod powrotu dla udanego żądania HTTP, ale nieudane wywołanie REST .

Jest źle mieszać kody stanu HTTP i kody stanu spoczynku.

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

Kody zwrotne HTTP są powiązane z samym HTTP Requestsobą. Wywołanie REST jest wykonywane przy użyciu żądania protokołu przesyłania hipertekstu i działa na niższym poziomie niż sama wywołana metoda REST. REST jest koncepcją / podejściem, a jego wynik jest wynikiem biznesowym / logicznym , podczas gdy kod wyniku HTTP to transportowym .

Na przykład zwracanie „404 Nie znaleziono”, gdy dzwonisz / users /, jest mylące, ponieważ może to oznaczać:

• Niepoprawny identyfikator URI (HTTP)
• Nie znaleziono użytkowników (REST)

„403 Zabroniony / Odmowa dostępu” może oznaczać:

• Potrzebne specjalne pozwolenie. Przeglądarki mogą sobie z tym poradzić, pytając użytkownika / hasło. (HTTP)
• Niepoprawne uprawnienia dostępu skonfigurowane na serwerze. (HTTP)
• Musisz być uwierzytelniony (REST)

Lista może być kontynuowana z błędem „500 Server error” (błąd rzucenia HTTP Apache / Nginx lub błąd ograniczeń biznesowych w REST) ​​lub innymi błędami HTTP itp.

Na podstawie kodu trudno zrozumieć, co było przyczyną niepowodzenia, awarii HTTP (transportu) lub awarii REST (logicznej).

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

Zamiast tego możesz zwrócić 200 kod HTTP z kilkoma opcjami:

• obiekt „error” w wyniku JSON, jeśli coś pójdzie nie tak
• Opróżnij tablicę / obiekt JSON, jeśli nie znaleziono rekordu
• Flaga wyniku bool / sukces w połączeniu z poprzednimi opcjami dla lepszej obsługi.

Ponadto niektórzy dostawcy Internetu mogą przechwytywać żądania i zwracać kod 404 HTTP. Nie oznacza to, że twoich danych nie znaleziono, ale na poziomie transportu coś jest nie tak.

Z Wiki :

W lipcu 2004 r. Brytyjski dostawca usług telekomunikacyjnych BT Group wdrożył system blokowania treści Cleanfeed, który zwraca błąd 404 w przypadku każdego żądania treści zidentyfikowanych przez Internet Watch Foundation jako potencjalnie nielegalne. W tych samych okolicznościach inni dostawcy usług internetowych zwracają błąd „zabronione” HTTP 403. Praktyka stosowania fałszywych błędów 404 jako sposobu na ukrycie cenzury została również zgłoszona w Tajlandii i Tunezji. W Tunezji, gdzie przed rewolucją w 2011 r. Cenzura była poważna, ludzie zdali sobie sprawę z natury fałszywych błędów 404 i stworzyli wymyśloną postać o imieniu „Ammar 404”, która reprezentuje „niewidzialnego cenzora”.

Dlaczego nie po prostu odpowiedzieć na coś takiego?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google zawsze zwraca 200 jako kod stanu w interfejsie API Geokodowania, nawet jeśli żądanie logicznie się nie powiedzie: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

Facebook zawsze zwraca 200 za pomyślne żądania HTTP, nawet jeśli żądanie REST nie powiedzie się: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling

To proste, kody stanu HTTP są dla żądań HTTP. Interfejs API REST należy do Ciebie, zdefiniuj kody stanu.

Duplikatem w bazie danych powinno być 409 CONFLICT.

Polecam używać 422 UNPROCESSABLE ENTITYdo błędów sprawdzania poprawności.

Podaję tutaj dłuższe wyjaśnienie kodów 4xx .

Kod stanu 304 niezmodyfikowany również dawałby akceptowalną odpowiedź na zduplikowane żądanie. Jest to podobne do przetwarzania nagłówka If-None-Matchprzy użyciu znacznika encji.

Moim zdaniem odpowiedź @ Piskvor jest bardziej oczywistym wyborem na to, co postrzegam, jest intencją pierwotnego pytania, ale mam alternatywę, która jest również istotna.

Jeśli chcesz traktować zduplikowane żądanie jako ostrzeżenie lub powiadomienie, a nie jako błąd, kod stanu odpowiedzi 304Niezmodyfikowany iContent-Location nagłówek identyfikujący istniejący zasób będą równie poprawne. Gdy celem jest jedynie zapewnienie istnienia zasobu, zduplikowane żądanie nie byłoby błędem, ale potwierdzeniem. Żądanie nie jest złe, ale jest po prostu nadmiarowe, a klient może odwoływać się do istniejącego zasobu.

Innymi słowy, żądanie jest dobre, ale ponieważ zasób już istnieje, serwer nie musi wykonywać żadnego dalszego przetwarzania.

Adapter ActiveRecord Ember-Data oczekuje 422 UNPROCESSABLE ENTITYna zwrot z serwera. Tak więc, jeśli twój klient jest napisany w Ember.js, powinieneś użyć 422. Tylko wtedy DS.Errors zostaną wypełnione zwracanymi błędami. Oczywiście możesz zmienić 422 na dowolny inny kod w adapterze.