Haruskah saya mengembalikan respons 204 atau 404 ketika sumber daya tidak ditemukan?

Saya mengembangkan layanan RESTful sederhana untuk turnamen dan jadwal. Ketika sebuah turnamen dibuat melalui permintaan POST yang berisi badan JSON, turnamen tersebut dimasukkan ke dalam BiMap, dinyatakan sebagai berikut dalam implementasi DAO:

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

Ketika sebuah turnamen dibuat, id string yang terkait dikembalikan sehingga pengguna dapat memiliki referensi di masa depan dari turnamen itu. Ia dapat memperoleh informasi kembali dari turnamen baru dengan melakukan permintaan berikut:

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

Tetapi bagaimana jika tidak ada turnamen dengan id seperti itu ditemukan? Sejauh ini, saya mengembalikan respons 204. Nah, Jersey melakukannya untuk saya ketika kembali nulldari salah satu metodenya. Ini adalah metode yang sesuai dengan rute di atas:

@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;
}

Pertanyaan saya adalah: apakah 204: No Contentboleh mengembalikan jawaban, atau haruskah itu 404balasan, karena sumber daya tidak ditemukan?

Jika saya harus mengubahnya ke 404, pertanyaan yang jelas: Saya harus mengubah metode tanda tangan kan? Karena sekarang turnamen (tipe Tournament) mungkin tidak dikembalikan, metodenya akan terlihat berbeda. Saya harus menggunakan Responsetipe sebagai jenis kembali bukan?

HTTP 204berarti bahwa sesuatu itu ditemukan, tapi itu kosong. Misalnya, bayangkan Anda menyajikan file log melalui HTTP, dengan permintaan seperti http://example.com/logs/[date-goes-here] . Pada 18 Mei 2015:

• http://example.com/logs/2015-05-19 akan kembali HTTP 404, yang berarti tidak ada log, karena, yah, sulit untuk mencatat masa depan.

• Namun, http://example.com/logs/2015-05-18 akan kembali HTTP 200dengan entri log dalam konten respons, atau HTTP 204jika file log dibuat, tetapi masih belum ada log yang tercatat untuk ini. tanggal.

Jika Anda memberikan nullkerangka kerja sebagai respons terhadap permintaan, itu mengasumsikan bahwa Anda menemukan entri, dan entri ini kosong HTTP 204. Sebagai gantinya, Anda harus throw new NotFoundException();menunjukkan kepada kerangka kerja bahwa entri tidak ada, sehingga akan menghasilkan a HTTP 404.

Jika saya harus mengubahnya ke 404, pertanyaan yang jelas: Saya harus mengubah metode tanda tangan kan?

Tidak, tidak. Itu hal yang baik tentang throw new NotFoundException();. Ini akan berfungsi apa pun jenis pengembalian aktual metode Anda.

Anda harus mengembalikan 404. Anda dapat melakukannya dengan melempar NotFoundException ( https://jersey.java.net/apidocs/2.6/jersey/javax/ws/rs/NotFoundException.html ).

Lihat juga pertanyaan SO ini jika Anda perlu mengontrol tipe konten yang dikembalikan /programming/23858488/how-i-return-http-404-json-xml-response-in-jax-rs- jersey-on-tomcat

Permintaan Anda adalah GET http://localhost:8080/eventscheduler/c15268ce-474a-49bd-a623-b0b865386f39.

Jika http://localhost:8080/eventscheduler/tidak ada sebagai titik akhir, Anda harus mengembalikan 404. Anda mencoba mengakses sumber daya ( /eventscheduler/) yang tidak ada. Ini akan menunjukkan kepada klien bahwa server ada localhost:8080, tetapi tidak ada di eventschedulertitik akhir.

Jika http://localhost:8080/eventscheduler/ada sebagai titik akhir tetapi sumber daya yang diperlukan tidak tersedia, kesalahan 5xx tepat. Contoh yang baik dari ini adalah jika database sedang offline, di mana Anda bisa mengembalikan 503. Tentu saja, Anda mungkin hanya ingin mengembalikan kesalahan 500 generik daripada contoh khusus.

Jika http://localhost:8080/eventscheduler/ada tetapi hal yang diwakili oleh c15268ce-474a-49bd-a623-b0b865386f39tidak ada, saya akan mengembalikan 200 dengan badan yang menunjukkan rincian. Titik akhir ada, permintaan yang dibuat benar-benar valid dan dapat diproses, tetapi tidak ada kecocokan.

Jika permintaan klien Anda ke titik akhir tidak valid, Anda akan melihat kesalahan 4xx lainnya. Anda dapat menunjukkan bahwa klien tidak berwenang untuk mengakses titik akhir atau item yang diminta dengan 401 atau 403 atau dapat menggunakan 400 untuk menunjukkan bahwa permintaan tersebut tidak valid. Dengan semua ini, informasi tambahan dapat diberikan di badan respons.