Nie powiedziałbym.
Dlaczego nie 404 (nie znaleziono)?
Kod stanu 404 powinien być zarezerwowany dla sytuacji, w których nie można znaleźć zasobu. W tym przypadku Twoim zasobem jest kolekcja użytkowników . Ta kolekcja istnieje, ale jest obecnie pusta. Osobiście byłbym bardzo zdezorientowany jako autor klienta dla twojej aplikacji, gdybym dostał 200
jeden dzień i 404
następny tylko dlatego, że ktoś zdarzyło się usunąć kilku użytkowników. Co powinienem zrobić? Czy mój adres URL jest nieprawidłowy? Czy ktoś zmienił API i zaniedbał pozostawienie przekierowania.
Dlaczego nie 204 (brak treści)?
Oto fragment opisu kodu stanu 204 przez w3c
Serwer spełnił żądanie, ale nie musi zwracać treści encji i może chcieć zwrócić zaktualizowane metainformacje.
Chociaż w tym przypadku może się to wydawać rozsądne, myślę, że wprowadzałoby to również w błąd klientów. A 204
ma wskazywać, że jakaś operacja została wykonana pomyślnie i nie trzeba zwracać żadnych danych. Jest to idealne rozwiązanie jako odpowiedź na DELETE
żądanie lub odpalenie jakiegoś skryptu, który nie musi zwracać danych. W przypadku api/users
domeny zazwyczaj oczekujesz reprezentacji swojej kolekcji użytkowników. Wysyłanie treści odpowiedzi raz, a nie wysyłanie jej innym razem jest niespójne i może wprowadzać w błąd.
Dlaczego miałbym używać 200 (OK)
Z powodów wymienionych powyżej (spójność) zwróciłbym reprezentację pustej kolekcji. Załóżmy, że używasz XML. Normalna treść odpowiedzi dla niepustej kolekcji użytkowników może wyglądać następująco:
<users>
<user>
<id>1</id>
<name>Tom</name>
</user>
<user>
<id>2</id>
<name>IMB</name>
</user>
</users>
a jeśli lista jest pusta, możesz po prostu odpowiedzieć w ten sposób (nadal używając a 200
):
<users/>
Tak czy inaczej, klient otrzymuje treść odpowiedzi w określonym, dobrze znanym formacie. Nie ma niepotrzebnego zamieszania i sprawdzania kodu statusu. Ponadto nie jest naruszana żadna definicja kodu stanu. Wszyscy są szczęśliwi.
Możesz zrobić to samo z JSON lub HTML lub jakimkolwiek formatem, którego używasz.