Czy powinienem zwrócić odpowiedź 204 lub 404, gdy nie znaleziono zasobu?

Rozwijam prostą usługę RESTful dla turniejów i harmonogramów. Gdy turniej jest tworzony na podstawie żądania POST zawierającego ciało JSON, turniej jest wstawiany do BiMap, zadeklarowanej w następujący sposób w implementacji DAO:

private BiMap<String, Tournament> tournaments = Maps.synchronizedBiMap(HashBiMap.create());

Po utworzeniu turnieju jest zwracany powiązany identyfikator ciągu, aby użytkownik mógł mieć w przyszłości odniesienia do tego turnieju. Może odzyskać informacje z nowego turnieju, wykonując następujące żądanie:

GET http://localhost:8080/eventscheduler/c15268ce-474a-49bd-a623-b0b865386f39

Ale co, jeśli nie zostanie znaleziony turniej o takim identyfikatorze? Do tej pory zwracam odpowiedź 204. Jersey robi to za mnie, wracając nullz jednej ze swoich metod. Jest to metoda, która odpowiada powyższej trasie:

@Path("/{id}")
@GET
@Produces(MediaType.APPLICATION_JSON)
public Tournament getTournament(@PathParam("id") String id) {
    Optional<Tournament> optTournament = tournamentDao.getTournament(id);
    if (optTournament.isPresent())
        return optTournament.get();
    return null;
}

Moje pytanie brzmi: czy odpowiedź jest w porządku 204: No Content, czy raczej powinna to być 404odpowiedź, ponieważ nie znaleziono zasobu?

Jeśli powinienem zmienić go na 404, oczywiste pytanie: powinienem zmienić podpis metody, prawda? Ponieważ teraz turniej (typu Tournament) może nie zostać zwrócony, metoda powinna wyglądać inaczej. Czy Responsezamiast tego powinienem użyć tego typu jako typu zwrotu?

HTTP 204oznacza, że coś zostało znalezione, ale jest pusty. Na przykład wyobraź sobie, że podajesz pliki dziennika za pośrednictwem protokołu HTTP z żądaniami takimi jak http://example.com/logs/[date-goes-here] . 18 maja 2015 r .:

• http://example.com/logs/2015-05-19 zwróci HTTP 404, co oznacza, że ​​nie ma dzienników, ponieważ, cóż, trudno jest zapisywać przyszłość.

• http://example.com/logs/2015-05-18 zwróci jednak albo HTTP 200wpisy dziennika w treści odpowiedzi, albo HTTP 204jeśli plik dziennika został utworzony, ale nadal nie ma zapisanych dzienników dla tego data.

Jeśli podasz nullramowi jako odpowiedź na żądanie, zakłada się, że znalazłeś wpis, a zatem ten wpis jest pusty HTTP 204. Zamiast tego powinieneś throw new NotFoundException();wskazać frameworkowi, że wpis nie istnieje, aby wygenerował HTTP 404.

Jeśli powinienem zmienić go na 404, oczywiste pytanie: powinienem zmienić podpis metody, prawda?

Nie, ty nie. To miło z tego powodu throw new NotFoundException();. Będzie działać bez względu na faktyczny typ zwracanej metody.

Powinieneś zwrócić 404. Możesz to zrobić, zgłaszając NotFoundException ( https://jersey.java.net/apidocs/2.6/jersey/javax/ws/rs/NotFoundException.html ).

Proszę również spojrzeć na to SO pytanie, jeśli chcesz kontrolować zwracany typ zawartości /programming/23858488/how-i-return-http-404-json-xml-response-in-jax-rs- jersey-on-tomcat

Twoja prośba to GET http://localhost:8080/eventscheduler/c15268ce-474a-49bd-a623-b0b865386f39.

Jeśli http://localhost:8080/eventscheduler/nie istnieje jako punkt końcowy, powinieneś zwrócić 404. Próbujesz uzyskać dostęp do zasobu ( /eventscheduler/), który nie istnieje. Oznaczałoby to klientowi, że serwer istnieje localhost:8080, ale nie ma nic w eventschedulerpunkcie końcowym.

Jeśli http://localhost:8080/eventscheduler/istnieje jako punkt końcowy, ale wymagane zasoby są niedostępne, odpowiedni jest błąd 5xx. Dobrym przykładem tego jest sytuacja, gdy baza danych jest w trybie offline, gdzie można zwrócić 503. Oczywiście możesz po prostu zwrócić ogólny błąd 500 zamiast określonej instancji.

Jeśli http://localhost:8080/eventscheduler/istnieje, ale rzecz reprezentowana przez c15268ce-474a-49bd-a623-b0b865386f39nie istnieje, zwróciłbym 200 z ciałem wskazującym szczegóły. Punkt końcowy istnieje, wykonane żądanie było całkowicie poprawne i mogło zostać przetworzone, ale nie znaleziono dopasowania.

Jeśli żądanie klienta do punktu końcowego było nieprawidłowe, sprawdzono by inne błędy 4xx. Możesz wskazać, że klient nie ma uprawnień dostępu do punktu końcowego lub żądanych elementów za pomocą 401 lub 403, lub możesz użyć 400, aby wskazać, że żądanie jest nieprawidłowe. W przypadku dowolnej z nich w treści odpowiedzi można podać dodatkowe informacje.