Praktik Handling Kesalahan API

13 Praktik Handling Kesalahan APIPraktik Handling Kesalahan API, Kode kesalahan hampir merupakan hal terakhir yg ingin Anda lihat dalam respons API. Secara umum, ini berarti salah satu dari dua hal — ada sesuatu yg salah dalam request atau Handling Anda sehingga API tidak bisa mengurai data yg diteruskan, atau API itu sendiri mempunyai begitu banyak masalah sehingga request yg paling baik pun akan berjalan. gagal. Dalam kedua situasi tersebut, lalu lintas menjadi macet, dan proses menemukan penyebab dan solusinya dimulai.

Karena itu, kesalahan, baik dalam bentuk kode atau respons kesalahan sederhana, agak mirip dengan mencoba — tidak menyenangkan, tetapi sangat berguna. Kode kesalahan mungkin merupakan elemen diagnostik yg paling berguna di ruang API, dan ini mengejutkan, mengingat betapa sedikit perhatian yg sering kita berikan kepada mereka.

Hari ini, kita akan berbicara tentang mengapa respons kesalahan dan pendekatan Handling sangat berguna dan penting. Kami akan melihat beberapa klasifikasi kode kesalahan umum yg akan dihadapi pengguna rata-rata, serta beberapa contoh kode ini dalam tindakan. Kami juga akan berbicara sedikit tentang apa yg membuat kode kesalahan “baik” dan apa yg membuat kode Praktik Handling Kesalahan API “buruk”, dan bagaimana memastikan kode kesalahan Anda habis.

Baca juga: Memperbaiki Kode Kesalahan HTTP

Praktik Handling Kesalahan API

Nilai Kode Kesalahan

Seperti yg telah kami katakan, kode kesalahan sangat berguna. Kode kesalahan dalam tahap respons API merupakan cara mendasar di mana pengembang bisa mengomunikasikan kegagalan kepada pengguna. Tahap ini, setelah tahap request awal, merupakan komunikasi langsung antara klien dan API. Ini sering kali merupakan langkah pertama dan terpenting untuk tidak hanya memberi tahu pengguna tentang kegagalan, tetapi juga memulai proses resolusi kesalahan.

Pengguna tidak memilih kapan Praktik Handling Kesalahan API dibuat, atau kesalahan apa yg di peroleh — situasi kesalahan sering muncul dalam kasus yg, bagi pengguna, sepenuhnya acak dan mencurigakan. Oleh karena itu, tanggapan kesalahan merupakan satu-satunya komunikasi yg benar-benar konstan dan konsisten yg bisa diandalkan pengguna ketika kesalahan telah terjadi. Kode kesalahan mempunyai nilai tersirat dalam cara keduanya memperjelas situasi, dan mengomunikasikan fungsionalitas yg dimaksudkan.

Pertimbangkan misalnya kode kesalahan seperti “401 Tidak Diotorisasi – Harap Lewati Token.” Dalam respons seperti itu, Anda memahami titik kegagalan, khususnya bahwa pengguna tidak sah. Namun, selain itu, Anda menemukan fungsionalitas yg dimaksud — API memerlukan token, dan token tersebut harus diteruskan sebagai bagian dari request untuk memperoleh otorisasi.

Dengan kode kesalahan sederhana dan penjelasan resolusi, Anda tidak hanya mengomunikasikan penyebab Praktik Handling Kesalahan API , tetapi fungsi dan metode yg dimaksudkan untuk memperbaiki kesalahan tersebut — itu sangat berharga, terutama untuk jumlah data yg sebenarnya dikembalikan.

Kode Status HTTP

Sebelum kita menyelam lebih dalam ke kode Praktik Handling Kesalahan API dan apa yg membuat kode “baik” menjadi “baik”, kita perlu membahas format Kode Status HTTP. Kode-kode ini merupakan kode status paling umum yg akan ditemui oleh rata-rata pengguna, tidak hanya dalam hal API tetapi dalam hal penggunaan internet secara umum. Sementara protokol lain ada dan mempunyai sistem kodenya sendiri, Kode Status HTTP mendominasi komunikasi API, dan kode khusus vendor cenderung diturunkan dari rentang ini.

1XX – Informasi

Rentang 1XX mempunyai dua fungsi dasar. yg pertama merupakan dalam transfer informasi yg berkaitan dengan status protokol perangkat yg terhubung — misalnya, 101 Switching Protocols merupakan kode status yg mencatat bahwa klien telah meminta perubahan protokol dari server, dan bahwa request tersebut telah disetujui. Rentang 1XX juga menjelaskan status request awal. 100 Continue, misalnya, mencatat bahwa server telah menerima header request dari klien, dan server sedang menunggu badan request.

2XX – Sukses

Rentang 2XX mencatat berbagai keberhasilan dalam komunikasi, dan mengemas beberapa tanggapan ke dalam kode-kode tertentu. Tiga kode status pertama dengan sempurna menunjukkan rentang ini – 200 OK berarti request GET atau POST berhasil, 201 Created mengonfirmasi bahwa request telah dipenuhi dan sumber daya baru telah dibuat untuk klien, dan 202 Accepted berarti request telah telah diterima, dan pemrosesan itu telah dimulai.

3XX – Pengalihan

Rentang 3XX merupakan semua tentang status sumber daya atau titik akhir. Ketika jenis kode status ini dikirim, itu berarti bahwa server masih menerima komunikasi, tetapi titik yg dihubungi bukanlah titik masuk yg benar ke dalam sistem. 301 Dipindahkan Secara permanen memverifikasi bahwa request klien sebenarnya mencapai sistem yg benar, tetapi request ini dan semua request di masa mendatang harus ditangani oleh URI yg berbeda. Ini sangat berguna dalam subdomain dan saat memindahkan sumber daya dari satu server ke server lainnya.

4XX – Kesalahan Klien

Seri kode kesalahan 4XX mungkin yg paling terkenal karena status 404 Not Found yg ikonik, yg merupakan penanda terkenal untuk URL dan URI yg salah bentuk. Namun, kode status lain yg lebih berguna untuk API ada dalam rentang ini.

414 URI Too Long merupakan kode status umum, yg menunjukkan bahwa data yg didorong dalam request GET terlalu panjang, dan harus dikonversi ke request POST. Kode umum lainnya merupakan 429 Terlalu Banyak request, yg digunakan untuk pembatasan tarif untuk mencatat bahwa klien mencoba terlalu banyak request sekaligus, dan lalu lintas mereka ditolak.

5XX – Kesalahan Server

Akhirnya rentang 5XX dicadangkan untuk kode kesalahan yg secara khusus terkait dengan fungsionalitas server. Sedangkan rentang 4XX merupakan tanggung jawab klien (dan dengan demikian menunjukkan kegagalan klien), rentang 5XX secara khusus mencatat kegagalan dengan server. Kode kesalahan seperti 502 Bad Gateway, yg mencatat server upstream telah gagal dan bahwa server saat ini merupakan gateway. Lebih lanjut mengekspos fungsionalitas server sebagai sarana untuk menunjukkan di mana kegagalan terjadi. Ada juga kegagalan umum yg kurang spesifik, seperti 503 Layanan Tidak Tersedia

Membuat Kode Praktik Handling Kesalahan API yg Baik

Dengan pemahaman yg kuat tentang Kode Status HTTP, kita bisa mulai membedah apa yg sebenarnya membuat kode kesalahan baik. Dan apa yg membuat kode kesalahan buruk. Kode kesalahan kualitas tidak hanya mengomunikasikan apa yg salah, tetapi juga mengapa kesalahan itu terjadi.

Kode kesalahan yg terlalu buram sangat tidak membantu. Bayangkan Anda mencoba membuat request GET ke API yg menangani inventaris musik digital. Anda telah mengirimkan request Anda ke API yg Anda tahu secara rutin menerima lalu lintas Anda. Dan Anda telah melewati kredensial otorisasi dan autentikasi yg benar, dan sepengetahuan Anda, server siap untuk merespons.

Anda mengirim data Anda, dan menerima kode kesalahan berikut – 400 request Buruk. Tanpa data tambahan, tanpa informasi lebih lanjut, apa yg sebenarnya dikatakan ini kepada Anda? Itu dalam kisaran 4XX, jadi Anda tahu masalahnya ada di sisi klien. Tetapi sama sekali tidak mengomunikasikan masalah itu sendiri selain “request buruk.”

Ini merupakan saat kode kesalahan “fungsional” benar-benar tidak berfungsi sebagaimana mestinya. Tanggapan yg sama bisa dengan mudah dibuat membantu dan transparan dengan sedikit usaha — tetapi apa artinya ini? Kode kesalahan yg baik harus melewati tiga kriteria dasar agar benar-benar membantu. Kode Praktik Handling Kesalahan API kualitas harus mencakup:

Untuk Kode Status HTTP, sehingga sumber dan ranah masalah bisa dipastikan dengan mudah;
ID Referensi Internal untuk notasi kesalahan khusus dokumentasi. Dalam beberapa kasus, ini bisa menggantikan Kode Status HTTP. Selama lembar referensi internal menyertakan skema Kode Status HTTP atau materi referensi serupa.
Pesan yg bisa dibaca manusia yg merangkum konteks, penyebab, dan solusi umum untuk kesalahan yg ada.

Sertakan Kode Status Standar

Pertama dan terpenting, setiap kode kesalahan yg dihasilkan harus mempunyai kode status terlampir. Meskipun ini sering berbentuk kode internal, biasanya berbentuk kode status standar dalam skema Kode Status HTTP. Dengan mencatat status menggunakan standarisasi yg sangat spesifik ini. Anda tidak hanya mengomunikasikan jenis kesalahan, Anda juga mengomunikasikan di mana kesalahan itu terjadi.

Ada implikasi tertentu untuk setiap rentang Kode Status HTTP, dan implikasi ini memberikan pengertian tentang tanggung jawab atas kesalahan tersebut. Kesalahan 5XX, misalnya, perhatikan bahwa kesalahan dihasilkan dari server. Dan bahwa perbaikannya pasti ada hubungannya dengan data terkait server, pengalamatan, dll. 4XX, sebaliknya, mencatat masalahnya ada pada klien, dan khususnya request dari klien atau status klien pada saat itu.

Dengan mengatasi kode kesalahan menggunakan status default. Anda bisa memberikan titik awal yg sangat berguna bahkan bagi pengguna dasar untuk memecahkan masalah Praktik Handling Kesalahan API mereka.