Powiedziałbym, że żadne z nich nie jest właściwe. Jak powiedziano - np. Przez @anneb, również uważam, że część problemów wynika z używania kodu odpowiedzi HTTP do transportu statusu związanego z usługą RESTful. Wszystko, co usługa REST ma do powiedzenia na temat własnego przetwarzania, powinno być transportowane za pomocą kodów specyficznych dla REST.
1
Twierdzę, że jeśli serwer HTTP znajdzie jakąkolwiek usługę, która jest gotowa odpowiedzieć na żądanie, które zostało wysłane, nie powinien odpowiedzieć HTTP 404 - w końcu coś zostało znalezione przez serwer - chyba że zostało to wyraźnie określone przez usługa przetwarzająca żądanie.
Załóżmy na chwilę następujący adres: http://example.com/service/return/test.
- Przypadek A polega na tym, że serwer „po prostu szuka pliku w systemie plików”. Jeśli nie jest obecny,
404jest poprawny. To samo jest prawdą, jeśli prosi jakąś usługę o dostarczenie dokładnie tego pliku, a ta usługa mówi mu, że nic o tej nazwie nie istnieje.
- W przypadku B serwer nie działa z „prawdziwymi” plikami, ale w rzeczywistości żądanie jest przetwarzane przez inną usługę - np. Jakiś system szablonów. W tym przypadku serwer nie może wysuwać żadnych roszczeń dotyczących istnienia zasobu, ponieważ nic o nim nie wie (o ile usługa go nie poinformuje).
Bez odpowiedzi ze strony usługi wyraźnie wymagającej innego zachowania serwer HTTP może powiedzieć tylko 3 rzeczy:
503 jeśli usługa, która ma obsłużyć żądanie, nie działa lub nie odpowiada;200 w przeciwnym razie serwer HTTP może faktycznie spełnić żądanie - bez względu na to, co powie później usługa;400lub 404wskazać, że nie ma takiej usługi (w przeciwieństwie do „istnieje, ale offline”) i nic innego nie znaleziono.
2)
Wracając do pytania: Myślę, że najczystszym podejściem byłoby w ogóle nie używać kodu odpowiedzi HTTP innego niż wspomniany wcześniej. Jeśli usługa jest obecna i odpowiada, kod HTTP powinien wynosić 200. Odpowiedź powinna zawierać status, który usługa zwróciła w osobnym nagłówku - tutaj usługa może powiedzieć
REST:EMPTYnp. jeśli został poproszony o wyszukanie czegoś i że badania wróciły puste;REST:NOT FOUNDgdyby został poproszony o coś. „Podobny do identyfikatora” - może to być nazwa pliku lub zasób według identyfikatora lub pozycji nr 24 itd. - i że nie znaleziono określonego zasobu (zwykle żądano jednego zasobu i nie znaleziono go);REST:INVALID jeśli jakakolwiek część żądania, które zostało wysłane, nie jest rozpoznawana przez usługę.
(zwróć uwagę, że poprzedziłem je słowem „REST:”, aby zaznaczyć fakt, że chociaż mogą mieć te same wartości lub sformułowania, co kody odpowiedzi HTTP, są zupełnie inne)
3)
Wróćmy do powyższego adresu URL i sprawdźmy przypadek B, w którym usługa wskazuje serwerowi HTTP, że sam nie obsługuje tego żądania, ale przekazuje je SERVICE. HTTP podaje tylko to, co zostało przekazane SERVICE, nie wie nic o tej return/testczęści, ponieważ jest to przedmiotem handlu SERVICE. Jeśli ta usługa jest uruchomiona, HTTP powinien powrócić, 200ponieważ rzeczywiście znalazł coś do obsługi żądania.
Status zwracany przez SERVICE(i który, jak wspomniano powyżej, chciałby zobaczyć w osobnym nagłówku), zależy od tego, czego się faktycznie oczekuje:
- jeśli
return/testpoprosi o określony zasób: jeśli istnieje, zwróć go ze statusem REST:FOUND; jeśli ten zasób nie istnieje, zwróć REST:NOT FOUND; można to rozszerzyć na zwrot, REST:GONEjeśli wiemy, że kiedyś istniał i nie wróci, a REST:MOVEDjeśli wiemy, że zniknął z Hollywood
- jeśli
return/testjest uważany za operację wyszukiwania lub filtrowania: jeśli zestaw wyników jest pusty, zwróć pusty zestaw żądanego typu i status REST:EMPTY; zestaw wyników w żądanym typie i statusREST:SUCCESS
- jeśli
return/testnie jest operacją rozpoznawaną przez SERVICE: zwróć, REST:ERRORjeśli jest całkowicie niepoprawna (np. literówka retrun/test), lub REST:NOT IMPLEMENTEDjeśli jest planowana na później.
4
To rozróżnienie jest o wiele czystsze niż mieszanie dwóch różnych rzeczy. Ułatwi to także debugowanie, a przetwarzanie będzie nieco bardziej skomplikowane, jeśli w ogóle.
- Jeśli zostanie zwrócony HTTP 404, serwer mówi mi: „Nie mam pojęcia, o czym mówisz”. Chociaż część REST mojej prośby może być wyjątkowo dobra, szukam par'Mach we wszystkich niewłaściwych miejscach.
- Z drugiej strony HTTP 200 i REST: ERR mówią mi, że dostałem usługę, ale zrobiłem coś złego w moim żądaniu do usługi.
- Z HTTP 200 i REST: PUSTY, wiem, że nie zrobiłem nic złego - właściwy serwer, serwer znalazł usługę, właściwe żądanie do usługi - ale wynik wyszukiwania jest pusty.
Podsumowanie
Problem i dyskusja wynikają z faktu, że kody odpowiedzi HTTP są używane do oznaczenia stanu usługi, której wyniki są obsługiwane przez HTTP, lub do oznaczenia czegoś. nie wchodzi to w zakres samego serwera HTTP. Z powodu tej rozbieżności na pytanie nie można odpowiedzieć, a wszystkie opinie są przedmiotem wielu dyskusji.
Stan żądania przetworzonego przez usługę, a nie serwer HTTP NAPRAWDĘ NIE POWINIEN (RFC 6919) podawany przez kod odpowiedzi HTTP. Kod HTTP POWINIEN (RFC 2119) zawiera tylko informacje, które serwer HTTP może podać ze swojego zakresu: mianowicie, czy stwierdzono, że usługa przetworzyła żądanie, czy nie.
Zamiast tego NALEŻY zastosować inny sposób poinformowania konsumenta o stanie zapytania do usługi, która faktycznie przetwarza żądanie. Moja propozycja polega na tym, aby zrobić to za pomocą określonego nagłówka. Idealnie zarówno nazwa nagłówka, jak i jego treść są zgodne ze standardem, który ułatwia konsumentom pracę z tymi odpowiedziami.
