Kode respons status HTTP apa yang harus saya gunakan jika permintaan tidak memiliki parameter yang diperlukan?


Jawaban:


388

Status 422 tampaknya paling tepat berdasarkan spesifikasi .

Kode status 422 (Entitas yang Tidak Dapat Diproses) berarti server memahami jenis konten entitas permintaan (oleh karena itu kode status 415 (Jenis Media yang Tidak Didukung) tidak pantas), dan sintaks entitas permintaan benar (dengan demikian 400 (Permintaan Buruk) ) kode status tidak pantas) tetapi tidak dapat memproses instruksi yang terkandung. Sebagai contoh, kondisi kesalahan ini dapat terjadi jika badan permintaan XML berisi formulasi XML yang baik (yaitu, benar secara sintaksis), tetapi secara semestinya salah.

Mereka menyatakan bahwa xml cacat adalah contoh sintaksis yang buruk (membutuhkan 400). String kueri yang salah bentuknya analog dengan ini, jadi 400 sepertinya tidak cocok untuk string kueri yang terbentuk dengan baik dan tidak memiliki param.

UPDATE @DavidV dengan benar menunjukkan bahwa spesifikasi ini untuk WebDAV, bukan HTTP inti. Tetapi beberapa API non-WebDAV yang populer menggunakan 422, karena tidak ada kode status yang lebih baik ( lihat ini ).


2
IMO Saya akan menggunakan ini ketika nilai dalam string kueri salah, bukan ketika ada nilai tambahan atau nilai yang hilang. yaitu. Mengharapkan e-mail dan nilainya '123123'
Derek Litz

2
Saya cenderung menganggap parameter GET dan POST sebagai metode tanda tangan dari jalur URL, jadi 404 masuk akal bagi saya. Dalam RESTful API yang dimaksudkan untuk konsumsi publik, lebih baik mengembalikan parameter yang hilang / ekstra. Dalam konteks URL, parameter string kueri biasanya penting untuk mengidentifikasi sumber daya dan parameter tambahan atau yang hilang mewakili sumber daya yang tidak ada, tanpa asumsi apa pun. Tentu saja, ada pertukaran dengan kekokohan dengan menjadi eksplisit, dan parameter opsional membuat sumber daya berpotensi sama rentan terhadap kesalahan diam. Lalu ada kegunaan ...
Derek Litz

13
Spesifikasi yang dirujuk adalah untuk WebDAV, dan bukan spesifikasi standar HTTP.
David V

1
@ Selvin Terima kasih telah menunjukkan posting blog itu. Sangat membantu untuk melihat bahwa Twitter, misalnya, menggunakan 422. Saya pikir jawabannya mungkin lebih baik jika Anda mengklarifikasi bahwa specnya adalah WebDAV di baris pertama. Ketika saya pertama kali membaca jawaban Anda, saya pikir Anda bermaksud spesifikasi standar HTTP sampai saya mengikuti tautan.
David V

3
Ini layak dibaca: bennadel.com/blog/... Saya tidak akan menggunakan 422 untuk param yang hilang juga. Saya pikir 400lebih tepat.
Zelphir Kaltstahl

184

Saya tidak yakin ada standar yang ditetapkan, tetapi saya akan menggunakan 400 Permintaan Buruk , yang mendokumentasikan spesifikasi HTTP terbaru (dari 2014) sebagai berikut :

6.5.1. 400 permintaan Buruk

Kode status 400 (Permintaan Buruk) menunjukkan bahwa server tidak dapat atau tidak akan memproses permintaan karena sesuatu yang dianggap sebagai kesalahan klien (misalnya, sintaks permintaan salah bentuk, pembingkaian pesan permintaan tidak valid, atau perutean permintaan yang menipu).


65
400 Bad Requestdimaksudkan untuk menunjukkan masalah tingkat protokol, bukan kesalahan semantik. Jika kita akan membajak kode status HTTP untuk menunjukkan kesalahan tingkat aplikasi (bukan tingkat protokol), mengapa tidak berjalan terus dan gunakan saja 412?
Matt Zukowski

36
Implementasi Google OAuth 1.0 setuju dengan jawaban ini. Respons 400 diberikan ketika parameter POST hilang atau tidak didukung: code.google.com/apis/accounts/docs/OAuth_ref.html
Tom

1
@ matt-zukowski: "412: Prasyarat yang diberikan dalam satu atau beberapa bidang header permintaan dievaluasi salah ketika diuji di server." from RFC2616 - Jika POST, parameternya ada di badan permintaan dan bukan kolom header-permintaan. Secara teknis, metode GET mengirimkan parameter itu di header-permintaan tetapi saya lebih suka memiliki konsistensi?
toong

6
@MattZukowski 400 adalah kode status tingkat aplikasi. Jika Anda melihat penulisan ulang dalam versi konsep RFC 7231 Anda akan melihatnya. Sayangnya, kata-kata dalam versi terbaru tidak begitu jelas karena penulis perubahan terbaru juga menemukan 422.
Darrel Miller

9
@DarrelMiller benar ( tautan langsung ): "Kode status 400 (Permintaan Buruk) menunjukkan bahwa server tidak dapat atau tidak akan memproses permintaan karena sesuatu yang dianggap sebagai kesalahan klien (mis. Sintaks permintaan salah bentuk, pesan permintaan tidak valid pembingkaian, atau perutean permintaan yang menipu). " Bergantung pada harapan semantik dan ekstensibilitas (akankah suatu hari dimungkinkan untuk mengeluarkan permintaan tanpa parameter?) Maka hanya 400 dan 404 yang tampaknya sesuai dalam HTTP standar. Lain, buat kode baru untuk API Anda, tetapi jangan membebani semantik.
mentega

31

The WCF API di NET menangani hilang parameter dengan mengembalikan sebuah HTTP 404kesalahan "Endpoint Tidak Ditemukan", ketika menggunakan webHttpBinding .

Masuk 404 Not Foundakal jika Anda mempertimbangkan nama metode layanan web Anda bersama-sama dengan tanda tangan parameternya. Artinya, jika Anda mengekspos metode layanan web LoginUser(string, string)dan Anda meminta LoginUser(string), yang terakhir tidak ditemukan.

Pada dasarnya ini berarti bahwa metode layanan web yang Anda panggil, bersama dengan tanda tangan parameter yang Anda tentukan, tidak dapat ditemukan.

10.4.5 404 Tidak Ditemukan

Server belum menemukan sesuatu yang cocok dengan Permintaan-URI. Tidak ada indikasi yang diberikan apakah kondisinya sementara atau permanen.

The 400 Bad Request, seperti Gert menyarankan , tetap kode respon yang valid, tapi saya pikir itu biasanya digunakan untuk menunjukkan masalah-tingkat yang lebih rendah. Itu bisa dengan mudah diartikan sebagai permintaan HTTP yang cacat, mungkin header HTTP yang hilang atau tidak valid, atau serupa.

10.4.1 400 Permintaan Buruk

Permintaan tidak dapat dipahami oleh server karena sintaksis yang salah. Klien TIDAK HARUS mengulangi permintaan tanpa modifikasi.


Inilah yang secara default dilakukan oleh CherryPy.
Derek Litz

Bagaimana ketika menangani permintaan pos di mana Anda menerima model dan bagian dari model itu hilang? Dalam hal ini Anda tidak mendapatkan 404. Sebaliknya Anda mendapatkan model yang tidak valid jika saya tidak salah dan Anda harus memutuskan apa yang harus dilakukan sekarang.
Shane Courtrille

1
Penafsiran ini tampaknya seperti peregangan, dan mengekspresikan RPC daripada REST pov. URI adalah pengidentifikasi, dan itu ada dan telah ditemukan. Apa yang dikirim dalam tubuh bukan bagian dari pengidentifikasi sumber daya. 422 lebih tepat.
Jonah

404 adalah jawaban yang tepat, cukup edit beberapa url di web untuk menemukan konsensus!
jenson-button-event

8

Anda dapat mengirim 400 kode Permintaan Buruk. Ini adalah salah satu kode status 4xx untuk keperluan umum, jadi Anda dapat menggunakannya untuk maksud yang Anda inginkan: klien mengirim permintaan yang kehilangan informasi / parameter yang diperlukan aplikasi Anda untuk memprosesnya dengan benar.


7

Dalam salah satu proyek API kami, kami memutuskan untuk menetapkan Status 409 untuk beberapa permintaan, ketika kami tidak dapat mengisinya penuh pada 100% karena parameter yang hilang.

Kode Status HTTP "409 Konflik" bagi kami merupakan upaya yang baik karena definisinya perlu menyertakan informasi yang cukup bagi pengguna untuk mengenali sumber konflik.

Referensi: w3.org/Protocols/

Jadi di antara tanggapan lain seperti 400 atau 404 kami memilih 409 untuk menegakkan kebutuhan untuk melihat beberapa catatan dalam permintaan yang membantu untuk membuat permintaan baru dan benar.

Bagaimanapun kasus kami adalah khusus karena kami harus mengirimkan beberapa data sebelum permintaan itu tidak sepenuhnya benar, dan kami perlu menegakkan klien untuk melihat pesan dan memahami apa yang salah dalam permintaan.

Secara umum jika kita hanya memiliki beberapa parameter yang hilang kita pergi untuk 400 dan array parameter yang hilang. Tetapi ketika kita perlu mengirim lebih banyak informasi, seperti pesan kasus tertentu dan kami ingin lebih yakin klien akan mengurusnya, kami mengirim 409


2
Ini jelas salah. 409 untuk masalah konkurensi karena @ MaximeGélinas menunjukkan ATAU situasi di mana sumber daya sudah ada dan duplikat tidak diizinkan.
gimlichael

Per spec, "Kode status 409 (Konflik) menunjukkan bahwa permintaan tidak dapat diselesaikan karena konflik dengan kondisi saat ini dari sumber daya target." . Menggunakannya untuk parameter yang hilang hanya salah; itu jenis kesalahan yang sama sekali berbeda.
Mark Amery

5

Saya biasanya menggunakan 422 (entitas yang tidak dapat diproses) jika sesuatu dalam parameter yang diperlukan tidak cocok dengan apa yang diperlukan API endpoint (seperti kata sandi yang terlalu pendek) tetapi untuk parameter yang hilang saya akan memilih 406 (Tidak dapat diterima).


8
Yah, 406 Tidak dapat diterima digunakan dengan header Terima (jika server tidak dapat mengirim respons klien akan mengerti). "Sumber daya yang diidentifikasi oleh permintaan hanya mampu menghasilkan entitas tanggapan yang memiliki karakteristik konten yang tidak dapat diterima sesuai dengan header penerima yang dikirim dalam permintaan." . Saya terjebak dengan 422 karena tidak ada pilihan "benar" dengan spesifikasi saat ini: - /
JakubKnejzlik

Menggunakan 406 untuk ini salah. Kode 406 tidak berarti bahwa permintaan itu tidak dapat diterima; itu berarti Anda tidak dapat memenuhi permintaan karena respons yang dapat Anda layani adalah tanggapan yang menurut klien tidak dapat diterima, berdasarkan tajuk Terima yang dikirim dalam permintaan. (Misalnya, permintaan disertakan Accept-Language: de, menunjukkan bahwa itu hanya akan menerima tanggapan dalam bahasa Jerman, tetapi satu-satunya versi dokumen yang diminta yang tersedia di server Anda adalah dalam bahasa Inggris atau Prancis.) Menggunakannya untuk menunjukkan parameter yang hilang dalam permintaan tidak benar, sesuai definisi dalam spesifikasi.
Mark Amery

3

Bagi mereka yang tertarik, Spring MVC (setidaknya 3.x) mengembalikan 400 dalam hal ini, yang tampaknya salah bagi saya.

Saya menguji beberapa URL Google (accounts.google.com) dan menghapus parameter yang diperlukan, dan mereka umumnya mengembalikan 404 dalam kasus ini.

Saya akan menyalin Google.


18
Karena Google melakukannya tidak secara otomatis berarti Google melakukannya dengan benar!
rve

4
Saya setuju, tidak selalu 'benar' tetapi kadang-kadang apa yang benar dan apa yang masuk akal adalah dua hal yang berbeda. Bagaimanapun .. terserah pembaca :)
Neromancer

Beberapa Google API mengembalikan 400, misalnya github.com/google/google-api-nodejs-client/issues/404
Dennis

yang salah (dan mengapa spring mvc tidak sesuai dengan jax-rs)
jenson-button-event

3

Dapat dikatakan bahwa a 404 Not Foundharus digunakan karena sumber daya yang ditentukan tidak dapat ditemukan.


3
Ini adalah perilaku default Java JAX-RS ketika parameter kueri tidak dapat dikonversi ke tipe data yang tepat. Saya tidak setuju dengan itu. Sumber daya ditemukan: parameter kueri untuk memfilter sumber daya dan salah satu filter diberikan dengan nilai yang tidak dapat diterima. Saya pikir ini cocok dengan 422 Entitas yang Tidak Dapat Diproses terdekat, dan 400 Permintaan Buruk terdekat kedua.
Ryan

ini adalah perilaku default dari jax-rs karena itu adalah perilaku yang benar!
jenson-button-event

Menggunakan 404 masuk akal ketika parameter string kueri dimaksudkan untuk mengidentifikasi sumber daya, nilai diberikan, tetapi nilai itu tidak sesuai dengan sumber daya yang ada - misalnya, jika Anda meminta example.com/show-user -profil? user_id = 123 dan pengguna 123 tidak ada. Tapi bukan itu yang ditanyakan pertanyaan ini; itu tentang skenario di mana parameter yang diperlukan dihilangkan seluruhnya. Saya tidak melihat bagaimana itu terkait dengan sumber daya yang ditentukan tidak ditemukan.
Mark Amery

2

Saya sering menggunakan 403 Forbidden error. Alasannya adalah bahwa permintaan itu dipahami, tetapi saya tidak akan melakukan seperti yang diminta (karena semuanya salah). Entitas respons menjelaskan apa yang salah, jadi jika responsnya adalah halaman HTML, pesan kesalahan ada di halaman. Jika respons JSON atau XML, informasi kesalahan ada di sana.

Dari rfc2616 :

10.4.4 403 Dilarang

Server mengerti permintaan itu, tetapi menolak untuk memenuhinya.
Otorisasi tidak akan membantu dan permintaan TIDAK HARUS diulang.
Jika metode permintaan itu bukan KEPALA dan server ingin mengumumkan kepada
publik mengapa permintaan itu belum terpenuhi, itu HARUS menggambarkan alasan penolakan di entitas. Jika server tidak ingin membuat informasi ini tersedia untuk klien, kode status 404
(Tidak Ditemukan) dapat digunakan sebagai gantinya.


4
Kedengarannya bagus pada awalnya, meskipun saya alami mengasosiasikan ini dengan otentikasi atau kesalahan berbasis izin. Juga, spesifikasi mengisyaratkan ke arah ini di mana dikatakan "jika server tidak ingin membuat informasi ini tersedia untuk klien". Juga bahwa 404 mungkin menjadi pilihan yang lebih baik. Saya akan menuju 404 atau 400 dari 403.
tonyhb

21
Ini adalah ide yang mengerikan, bahkan jika secara teknis terdengar. 403 secara universal digunakan untuk respons kegagalan auth, dan Anda akan membingungkan para klien Anda jika Anda mencoba menggunakan ini untuk menunjukkan kesalahan parameter. Misalnya, Twitter melakukan ini - 403 digunakan baik ketika Anda memberikan kredensial OAuth yang tidak valid, dan ketika ada sesuatu yang secara semantik salah dengan permintaan Anda - dan itu merupakan sumber kebingungan konstan untuk klien API.
Matt Zukowski

1
@ MatZukowski baik itu salah. Spesifikasi mengatakan Authorization will not help, jadi Twitter tidak boleh mengirim ini untuk kredensial OAuth yang tidak valid.
Torvin

@torvin Twitter seharusnya mengirim email sebagai 401 Unauthorizedgantinya. Namun, Anda dapat memahami mengapa mereka tidak melakukannya jika Anda melihat deskripsi dokumen MDN tentang kedua kode ini, yang sangat mirip.
Agi Hammerthief

-1

Hanya untuk menggunakan ASP.NET Core sebagai referensi atau contoh, ASP.NET Core memungkinkan Anda merancah pengontrol dengan tindakan, ini adalah bagaimana tindakan "Rincian" terlihat.

    // GET: Cars/Details/5
    public async Task<IActionResult> Details(int? id)
    {
        if (id == null)
        {
            return NotFound();
        }

        var car = await _context.Cars.FirstOrDefaultAsync(m => m.CarId == id);
        if (car == null)
        {
            return NotFound();
        }

        return View(car);
    }

Jika parameter idtidak disetel, maka mengembalikan 404 Tidak Ditemukan.


-5

Kembalikan 404 - yang berarti sumber daya tidak dapat ditemukan.

Coba edit url situs yang berisi id. Saya mencoba beberapa:

  • masalah repo gitub
  • halaman pertemuan
  • tampilan produk amazon
  • daftar ebay
  • artikel berita bbc

Semua kembali 404, imo karena para pengembang menafsirkan standar dengan benar, yang jawabannya di sini dan banyak lainnya, tidak!


1
Saya percaya sebagian besar devs mendefinisikan "parameter" sebagai salah satu pasangan nama / nilai dalam string kueri atau bentuk badan POST. Permintaan masalah repo Github tidak mengandung ini.
Kelvin

@ Selvin we devs juga menyertakan parameter jalur dalam daftar. jika parameter URL APA SAJA adalah wajib, mewakili lokasi sumber daya dan tidak termasuk, maka 404 harus dikembalikan. Ini tidak termasuk requestBody.
jenson-button-event

-6

Saya akan pergi dengan 403.

Dari RFC 2616 - Protokol Transfer Hiperteks - HTTP / 1.1

403 Dilarang

Server mengerti permintaan itu, tetapi menolak untuk memenuhinya. Otorisasi tidak akan membantu dan permintaan TIDAK HARUS diulang. Jika metode permintaan itu bukan KEPALA dan server ingin mengumumkan kepada publik mengapa permintaan itu belum terpenuhi, itu HARUS menggambarkan alasan penolakan di entitas. Jika server tidak ingin membuat informasi ini tersedia untuk klien, kode status 404 (Tidak Ditemukan) dapat digunakan sebagai gantinya.

Anda harus menjelaskan alasan kegagalan dalam respons Anda. Jika Anda memilih untuk tidak melakukannya, gunakan saja 404.


3
downvoted karena ini adalah jawaban rangkap. Pertimbangkan untuk menambahkan kalimat terakhir Anda sebagai komentar pada jawaban yang lebih lama yang menawarkan untuk menggunakan 403
pengguna
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.