Rujukan Terbaik untuk Kod Status HTTP dalam Reka Bentuk API

Dalam dunia pembangunan web dan reka bentuk API, kod status HTTP memainkan peranan penting dalam menyampaikan hasil permintaan antara pelanggan dan pelayan. Kod ini menyediakan cara piawai untuk menunjukkan keadaan, kejayaan atau ralat tertentu yang berlaku semasa pemprosesan permintaan HTTP. Memahami kod status ini adalah penting untuk pembangun, kerana ia membantu dalam penyahpepijatan, pengendalian ralat dan mencipta aplikasi yang lebih mantap.

1. 1xx Bermaklumat

Kod status ini menunjukkan respons sementara. Ia jarang digunakan dalam amalan tetapi boleh membantu dalam senario tertentu.

• 100 Teruskan: Pelayan telah menerima pengepala permintaan dan pelanggan harus meneruskan menghantar badan permintaan.
• 101 Menukar Protokol: Peminta telah meminta pelayan menukar protokol dan pelayan telah bersetuju untuk berbuat demikian.

2. 2xx Kejayaan

Kod status ini menunjukkan bahawa permintaan pelanggan telah berjaya diterima, difahami dan diterima.

• 200 OK: Permintaan berjaya, dan respons mengandungi data atau hasil yang diminta.
  • Contoh: Mendapatkan semula maklumat profil pengguna.
• 201 Dibuat: Permintaan telah berjaya dan sumber baharu telah dibuat.
  • Contoh: Mencipta akaun pengguna baharu atau menyiarkan entri blog baharu.
• 204 Tiada Kandungan: Pelayan berjaya memproses permintaan tetapi tidak mengembalikan sebarang kandungan.
  • Contoh: Mengemas kini tetapan pengguna yang tiada badan respons diperlukan.
• 206 Kandungan Separa: Pelayan hanya menghantar sebahagian daripada sumber disebabkan pengepala julat yang dihantar oleh klien.
  • Contoh: Menstrim kandungan video atau memuat turun fail besar dalam ketulan.

3. 3xx Ubah hala

Kod status ini menunjukkan bahawa tindakan lanjut perlu diambil oleh ejen pengguna untuk memenuhi permintaan.

• 301 Dialihkan Secara Kekal: Sumber yang diminta telah dialihkan secara kekal ke URL baharu.
• 302 Ditemui: Sumber yang diminta berada di bawah URL lain buat sementara waktu.
• 304 Tidak Diubahsuai: Menunjukkan bahawa sumber tidak diubah suai sejak versi yang ditentukan oleh pengepala permintaan.

4. Ralat Pelanggan 4xx

Kod status ini bertujuan untuk situasi di mana pelanggan nampaknya telah melakukan kesilapan.

• 400 Permintaan Buruk: Pelayan tidak dapat memproses permintaan kerana sintaks yang tidak sah atau input yang tidak baik.

  • Contoh: Menghantar JSON yang cacat dalam badan permintaan.
  • Penggunaan: Gunakan apabila permintaan itu sendiri salah bentuk atau mengandungi parameter tidak sah.

• 401 Tanpa Kebenaran: Permintaan memerlukan pengesahan pengguna.

  • Contoh: Percubaan untuk mengakses titik akhir API yang dilindungi tanpa memberikan bukti kelayakan yang sah.
  • Penggunaan: Gunakan apabila pengesahan diperlukan dan belum diberikan atau tidak sah.

• 403 Dilarang: Pelayan memahami permintaan itu tetapi enggan membenarkannya.

  • Contoh: Pengguna yang cuba mengakses ciri pentadbir sahaja.
  • Penggunaan: Gunakan apabila pengguna disahkan tetapi tidak mempunyai kebenaran untuk operasi yang diminta.

• 404 Tidak Ditemui: Sumber yang diminta tidak dapat ditemui pada pelayan.

  • Contoh: Percubaan untuk mendapatkan semula profil pengguna yang dipadamkan.
  • Penggunaan: Gunakan apabila sumber yang diminta tidak wujud.

• Kaedah 405 Tidak Dibenarkan: Kaedah yang dinyatakan dalam permintaan tidak dibenarkan untuk sumber yang dikenal pasti oleh URI permintaan.

  • Contoh: Menghantar permintaan POST ke titik akhir yang hanya menerima permintaan GET.

• 409 Konflik: Permintaan tidak dapat diproses kerana konflik dengan keadaan semasa sumber.

  • Contoh: Cuba mencipta pengguna dengan e-mel yang telah wujud dalam sistem.
  • Penggunaan: Gunakan apabila terdapat konflik dengan keadaan semasa sumber, seperti entri pendua.

• 422 Entiti Tidak Boleh Diproses: Pelayan memahami jenis kandungan dan sintaks permintaan, tetapi tidak boleh memproses arahan yang terkandung.

  • Contoh: Menyerahkan borang dengan data tidak sah yang gagal pengesahan bahagian pelayan.
  • Penggunaan: Gunakan untuk ralat pengesahan apabila sintaks permintaan adalah betul, tetapi datanya tidak betul dari segi semantik.

• 429 Terlalu Banyak Permintaan: Pengguna telah menghantar terlalu banyak permintaan dalam tempoh masa tertentu ("penghad kadar").

  • Contoh: Melaksanakan pengehadan kadar API untuk mengelakkan penyalahgunaan.

5. Ralat Pelayan 5xx

Kod status ini menunjukkan kes di mana pelayan menyedari bahawa ia telah mengalami ralat atau sebaliknya tidak mampu melaksanakan permintaan.

• Ralat Pelayan Dalaman 500: Mesej ralat generik yang menunjukkan bahawa pelayan menghadapi keadaan yang tidak dijangka yang menghalangnya daripada memenuhi permintaan.

  • Contoh: Pengecualian yang tidak dikendalikan berlaku dalam kod sebelah pelayan.

• 501 Tidak Dilaksanakan: Pelayan tidak menyokong fungsi yang diperlukan untuk memenuhi permintaan.

  • Contoh: Menggunakan kaedah HTTP baharu yang tidak dikenali oleh pelayan.

• 502 Bad Gateway: Pelayan, semasa bertindak sebagai get laluan atau proksi, menerima respons tidak sah daripada pelayan huluan.

  • Contoh: Pelayan proksi terbalik tidak boleh menyambung ke pelayan asal.

• Perkhidmatan 503 Tidak Tersedia: Pelayan pada masa ini tidak dapat mengendalikan permintaan kerana beban berlebihan atau penyelenggaraan sementara.

  • Contoh: Pelayan sedang menjalani penyelenggaraan berjadual atau mengalami trafik yang tinggi.

• 504 Gateway Timeout: Pelayan, semasa bertindak sebagai get laluan atau proksi, tidak menerima respons tepat pada masanya daripada pelayan huluan.

  • Contoh: Tamat masa berlaku semasa menunggu respons daripada API pihak ketiga.

Amalan Terbaik untuk Menggunakan Kod Status HTTP

1. Jadilah Spesifik: Gunakan kod status paling khusus yang digunakan untuk situasi tersebut. Ini membantu pelanggan memahami dengan tepat apa yang berlaku dan cara bertindak balas.

2. Penggunaan Konsisten: Kekalkan konsistensi dalam cara anda menggunakan kod status merentas API anda. Ini memudahkan pembangun bekerja dengan API anda.

3. Berikan Maklumat Tambahan: Bersama-sama dengan kod status, sertakan mesej ralat terperinci dalam badan respons apabila sesuai. Ini boleh membantu dengan nyahpepijat dan meningkatkan pengalaman pembangun.

4. Pertimbangan Keselamatan: Berhati-hati untuk mendedahkan terlalu banyak maklumat dalam respons ralat, terutamanya untuk ralat 4xx dan 5xx. Elakkan daripada mendedahkan butiran sensitif tentang seni bina atau pelaksanaan sistem anda.

5. Dokumentasi: Dokumenkan dengan jelas kod status yang digunakan oleh API anda dan dalam keadaan apa. Ini membantu pengguna API memahami cara mentafsir dan mengendalikan respons yang berbeza.

Dengan memahami dan melaksanakan kod status HTTP dengan betul, pembangun boleh mencipta API dan aplikasi web yang lebih mantap, jelas dan mesra pengguna. Kod ini berfungsi sebagai alat komunikasi penting antara pelanggan dan pelayan, membantu memperkemas pengendalian ralat dan meningkatkan kebolehpercayaan sistem secara keseluruhan.

Atas ialah kandungan terperinci Rujukan Terbaik untuk Kod Status HTTP dalam Reka Bentuk API. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!