http HEAD vs kinerja GET

Saya sedang menyiapkan layanan web REST yang hanya perlu menjawab YA atau TIDAK, secepat mungkin.

Merancang layanan HEAD tampaknya merupakan cara terbaik untuk melakukannya tetapi saya ingin tahu apakah saya benar-benar akan mendapatkan waktu versus melakukan permintaan GET.

Saya kira saya mendapatkan aliran tubuh untuk tidak dibuka / ditutup di server saya (sekitar 1 milidetik?). Karena jumlah byte yang dikembalikan sangat rendah, apakah saya memperoleh waktu dalam pengangkutan, dalam nomor paket IP?

Terima kasih sebelumnya atas tanggapan Anda!

Edit:

Untuk menjelaskan lebih lanjut konteksnya:

• Saya memiliki satu set layanan REST yang menjalankan beberapa proses, jika mereka dalam keadaan aktif.
• Saya memiliki layanan REST lain yang menunjukkan status semua layanan pertama ini.

Karena layanan terakhir akan sering dipanggil oleh sekumpulan klien yang sangat besar (satu panggilan diharapkan setiap 5 ms), saya bertanya-tanya apakah menggunakan metode HEAD dapat menjadi pengoptimalan yang berharga? Sekitar 250 karakter dikembalikan dalam isi respons. Metode HEAD setidaknya mendapatkan pengangkutan 250 karakter ini, tetapi apa dampaknya?

Saya mencoba untuk membandingkan perbedaan antara kedua metode (HEAD vs GET), menjalankan 1000 kali panggilan, tetapi tidak melihat keuntungan sama sekali (<1ms) ...

URI RESTful harus mewakili "sumber daya" di server. Sumber daya sering kali disimpan sebagai catatan dalam database atau file pada sistem file. Kecuali sumber daya besar atau lambat untuk diambil di server, Anda mungkin tidak melihat keuntungan terukur dengan menggunakan, HEADbukan GET. Bisa jadi mengambil meta data tidak lebih cepat daripada mengambil seluruh sumber daya.

Anda dapat menerapkan kedua opsi dan membandingkannya untuk melihat mana yang lebih cepat, tetapi daripada pengoptimalan mikro, saya akan fokus untuk merancang antarmuka REST yang ideal. REST API yang bersih biasanya lebih berharga dalam jangka panjang daripada API kludgey yang mungkin lebih cepat atau tidak. Saya tidak mengecilkan hati penggunaan HEAD, hanya menyarankan agar Anda hanya menggunakannya jika desainnya "tepat".

Jika informasi yang Anda perlukan benar-benar adalah meta data tentang sumber daya yang dapat direpresentasikan dengan baik di header HTTP, atau untuk memeriksa apakah sumber daya ada atau tidak, HEADmungkin berfungsi dengan baik.

Misalnya, Anda ingin memeriksa apakah sumber daya 123 ada. A 200berarti "ya" dan yang 404berarti "tidak":

HEAD /resources/123 HTTP/1.1
[...]

HTTP/1.1 404 Not Found
[...]

Namun, jika "ya" atau "tidak" yang Anda inginkan dari layanan REST adalah bagian dari resource itu sendiri, bukan meta data, Anda harus menggunakan GET.

Saya menemukan jawaban ini ketika mencari pertanyaan yang sama dengan yang diajukan oleh pemohon. Saya juga menemukan ini di http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html :

Metode HEAD identik dengan GET, kecuali bahwa server TIDAK HARUS mengembalikan badan pesan dalam respons. Metainformation yang terdapat dalam header HTTP sebagai tanggapan atas permintaan HEAD HARUS identik dengan informasi yang dikirim sebagai tanggapan atas permintaan GET. Metode ini dapat digunakan untuk memperoleh metainformasi tentang entitas yang tersirat oleh permintaan tanpa mentransfer badan-entitas itu sendiri. Metode ini sering digunakan untuk menguji tautan hypertext untuk validitas, aksesibilitas, dan modifikasi terbaru.

Tampaknya bagi saya jawaban yang benar untuk pertanyaan pemohon adalah bahwa itu tergantung pada apa yang diwakili oleh protokol REST. Misalnya, dalam kasus khusus saya, protokol REST saya digunakan untuk mengambil gambar yang cukup besar (seperti di lebih dari 10K). Jika saya memiliki sejumlah besar sumber daya yang diperiksa secara konstan, dan mengingat bahwa saya menggunakan header permintaan, maka masuk akal untuk menggunakan permintaan HEAD, sesuai rekomendasi w3.org.

Saya sangat tidak menyarankan pendekatan semacam ini.

Layanan RESTful harus menghormati semantik kata kerja HTTP. Kata kerja GET dimaksudkan untuk mengambil konten sumber daya, sedangkan kata kerja HEAD tidak akan mengembalikan konten apa pun dan dapat digunakan, misalnya, untuk melihat apakah sumber daya telah berubah, untuk mengetahui ukuran atau tipenya, untuk memeriksa apakah itu ada, dan seterusnya.

Dan ingat: pengoptimalan awal adalah akar dari segala kejahatan.

Performa Anda tidak akan berubah dengan menggunakan permintaan HEAD daripada permintaan GET.

Selanjutnya ketika Anda ingin REST-ful dan Anda ingin mendapatkan data, Anda harus menggunakan permintaan GET daripada permintaan HEAD.

GET mengambil kepala + badan, HEAD hanya mengambil kepala. Bukan masalah pendapat mana yang lebih cepat. Saya tidak mengerti jawaban positif di atas. Jika Anda mencari informasi META daripada mencari HEAD, yang dimaksudkan untuk tujuan ini.

Saya tidak mengerti kekhawatiran Anda tentang 'aliran tubuh yang terbuka / tertutup'. Isi respons akan melewati aliran yang sama dengan header respons http dan TIDAK akan membuat koneksi kedua (yang lebih dalam kisaran 3-6 md).

Ini sepertinya upaya pengoptimalan yang sangat matang sebelumnya pada sesuatu yang tidak akan membuat perbedaan yang signifikan atau bahkan dapat diukur. Perbedaan sebenarnya adalah kesesuaian dengan REST secara umum, yang merekomendasikan penggunaan GET untuk mendapatkan data ..

Jawaban saya TIDAK, gunakan GET jika masuk akal, tidak ada peningkatan kinerja menggunakan HEAD.

Permintaan HEAD sama seperti permintaan GET , kecuali isi responsnya kosong. Jenis permintaan ini dapat digunakan jika yang Anda inginkan hanyalah metadata tentang file tetapi tidak perlu memindahkan semua data file.

Anda dapat dengan mudah membuat tes kecil untuk mengukur kinerja Anda sendiri. Saya pikir perbedaan kinerja akan dapat diabaikan, karena jika Anda hanya mengembalikan 'Y' atau 'N' di badan, itu adalah satu byte tambahan yang ditambahkan ke aliran yang sudah terbuka.

Saya juga akan memilih GET karena lebih tepat. Anda tidak seharusnya menampilkan konten dalam header HTTP, hanya metadata.