Kode status HTTP yang disarankan untuk respons "batas rencana terlampaui"


24

Saya merancang REST API untuk proyek di mana pengguna selalu menggunakan salah satu dari beberapa "paket" - setiap paket menentukan beberapa batasan sumber daya, seperti jumlah maksimal pengguna yang mungkin dimiliki akun atau jumlah maksimum data yang dapat mereka unggah. Setelah salah satu dari batasan ini tercapai, pengguna dapat meningkatkan rencana mereka (pada dasarnya membayar) untuk mendapatkan lebih banyak sumber daya.

Saya ingin mengembalikan kode status khusus yang menunjukkan situasi di mana tindakan tidak dapat dilakukan karena batas sumber daya akun, dan memutakhirkan paket akan menyelesaikan ini - misalnya jika pengguna menggunakan 100% dari kapasitas penyimpanan mereka dan mencoba mengunggah file tambahan , mereka akan mendapatkan respons ini.

Para kandidat adalah, IMHO:

  • 403 Forbidden - Namun, saya ingin membedakan antara kasus ini dan kasus-kasus lain di mana pengguna tidak memiliki izin untuk melakukan tindakan ini.

  • 401 Unauthorized - bukan ide yang baik, kami menggunakan ini untuk masalah terkait otentikasi.

  • 402 Payment Required - masuk akal tapi saya khawatir menggunakan kode status yang non-standar namun dicadangkan

  • Sesuatu yang bahkan kurang standar seperti 423 Lockedtidak mungkin kita akan menggunakannya untuk hal lain di masa depan

Pilihan lain adalah menggunakan sesuatu yang sangat standar seperti 403tetapi menunjukkan kekhasan kesalahan dalam badan tanggapan.

Saya ingin tahu pendekatan mana yang Anda yakini akan (a) bekerja paling baik dalam jangka panjang dan (b) akan lebih baik berpegang pada prinsip RESTful.


1
Ada HTTP 507 Insufficient Storage.
CodesInChaos

RFC4331 mungkin relevan, ini tentang batas kuota untuk WebDAV.
CodesInChaos

@CodesInChaos ini seharusnya tidak menjadi kesalahan 5xx, dan penyimpanan hanyalah sebuah contoh (proyek sebenarnya bukan tentang penyimpanan sama sekali sebenarnya, itu hanya analogi yang baik).
shevron

Kode status respons HTTP 429 Terlalu Banyak Permintaan menunjukkan bahwa pengguna telah mengirim terlalu banyak permintaan dalam jumlah waktu tertentu
ExtractTable.com

Jawaban:


17

Saya pikir 403 adalah satu-satunya respons yang masuk akal, meskipun 405 Metode Tidak Diizinkan atau 409 Konflik mungkin dapat diterima, saya tidak berpikir keduanya sebagus 403 yang menyatakan:

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 tersebut belum terpenuhi, itu HARUS menggambarkan alasan penolakan di entitas

Jika Anda mengembalikan kesalahan 403, itu akan mencakup beberapa informasi tentang mengapa sumber daya ditolak - izin yang tidak valid hanyalah kasus yang paling umum, melampaui batas tidak jauh berbeda - Anda tidak memiliki izin karena batas Anda terlampaui.


22

Saya percaya 403 salah, karena 403 adalah untuk situasi di mana Anda tidak mendapatkan akses ke sumber daya, dan tidak ada cara apa pun untuk mendapatkan akses. Untuk pelanggan Anda, jelas ada cara untuk mendapatkan akses: Membayar.

401 benar-benar salah, karena Anda tidak hanya menggunakannya untuk otentikasi, tetapi untuk itulah ia ada.

Karena Anda menulis API, saya berasumsi bahwa orang lain harus menulis kode yang menggunakan API, dan orang itu perlu membaca spesifikasi API Anda. Anda mungkin menggunakan 429 "Terlalu banyak permintaan". Ini biasanya dimaksudkan untuk membatasi tingkat (di mana klien dapat membuat 100 permintaan per hari, misalnya), tetapi berlaku secara wajar untuk situasi Anda. 402 (Dibutuhkan pembayaran) juga bisa diterima, saya pikir. Tergantung pada alat apa yang Anda harapkan orang untuk menggunakan API Anda. 429 memiliki risiko bahwa alat pintar mencoba mengirim lebih sedikit permintaan per menit / jam / hari dan tidak pernah berhasil.

BTW menurut https://tools.ietf.org/html/rfc6585 kesalahan 429 juga harus berisi pesan html yang menggambarkan sifat masalah, jadi ada kemungkinan besar bahwa pengguna benar-benar diberi tahu apa masalahnya, jika Anda menyediakan informasi itu dalam respons Anda.


1
402adalah pilihan, tetapi saya lebih memilih untuk memesan 429untuk keperluan pembatasan tingkat aktual yang kemungkinan akan kita tambahkan di masa depan
shevron

Google tampaknya menggunakan403 meskipun saya suka 429jauh lebih baik. Saya telah melihat beberapa implementasi kustom dari klien http yang melakukan beberapa hal aneh 401dan 403(misalnya situs web akan mengeluarkan pengguna jika pernah mendapatkan 401 atau 403 dari api).
Cristian Vrabie

0

WebDAV menggunakan HTTP 507 Insufficient Storage untuk ini dan menyertakan kode kesalahan tambahan untuk kuota yang terlampaui di badan permintaan, untuk membedakannya dari jenis keterbatasan penyimpanan lainnya.


12
Tampaknya berlawanan dengan intuisi untuk menggunakan kode 5xx untuk ini.
Ben Aaronson
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.