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

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.

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.

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.

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.