Metode HTTP, kode status, dan jenis respons
Pendahuluan
Anda telah mengetahui bahwa metode HTTP dan kode status memainkan peran penting dalam REST API. Penting untuk mengikuti konvensi metode HTTP dan kode status karena dua alasan. Pertama, jika Anda mengikuti konvensi dari fase pengembangan, akan lebih mudah untuk menghindari bug pada kode Anda dan men-deploy proyek akhir pada server produksi. Kedua, memudahkan pengembang lain untuk menggunakan API Anda. Bacaan ini menyoroti metode HTTP yang paling penting, kode status, dan jenis respons API yang akan Anda gunakan saat mengerjakan proyek API.
Metode HTTP
Dalam dunia REST API, satu titik akhir dapat melakukan banyak tugas. Endpoint tersebut dapat mengirimkan sumber daya, membuat sumber daya baru, memperbarui, atau menghapusnya. Titik akhir tetap sama sementara tindakannya bervariasi. Ketika klien memanggil API, bagaimana pengembang API mengetahui tindakan mana yang harus dilakukan? Di sinilah metode HTTP berperan.
Metode HTTP atau tipe permintaan memberi tahu titik akhir API apa yang harus dilakukan dengan sumber daya. Metode ini mendefinisikan tindakan. Pengembang API membuat keputusan dan memanipulasi sumber daya dengan tepat berdasarkan metode HTTP dalam permintaan HTTP. Berikut ini daftar metode HTTP yang paling sering digunakan dan tindakan mana yang harus Anda lakukan untuk panggilan tersebut.
Metode HTTP | Tindakan |
|---|---|
GET | Mengembalikan sumber daya yang diminta. Jika tidak ditemukan, mengembalikan kode status 404 Not Found. |
POST | Membuat catatan. Permintaan POST selalu disertai dengan badan permintaan HTTP yang berisi data yang disandikan JSON atau URL Formulir, yang juga disebut muatan. Jika datanya valid, titik akhir API akan membuat sumber daya baru berdasarkan data tersebut. Meskipun Anda dapat membuat beberapa sumber daya dengan satu panggilan POST, hal ini tidak dianggap sebagai praktik terbaik untuk melakukannya. |
PUT | Menginstruksikan API untuk mengganti sumber daya. Seperti permintaan POST, permintaan PUT juga dilengkapi dengan data. Permintaan PUT biasanya memberikan semua data untuk sumber daya tertentu sehingga pengembang API dapat mengganti sumber daya tersebut dengan data yang disediakan. Permintaan PUT berhubungan dengan satu sumber daya. |
PATCH | Memerintahkan API untuk memperbarui sebagian sumber daya. Perhatikan perbedaan antara panggilan PUT dan PATCH. Panggilan PUT menggantikan sumber daya secara keseluruhan, sedangkan panggilan PATCH hanya memperbarui beberapa bagian. Permintaan PATCH juga berurusan dengan satu catatan. |
DELETE | Memerintahkan API untuk menghapus sumber daya. |
Contoh panggilan
Metode HTTP | Contoh titik akhir | String kueri / muatan |
|---|---|---|
GET | /api/menu-items /api/meu-items/1 /api/menu-items?category=appetizers /api/menu-items?perpage=3&page=2 | Panggilan GET tidak memerlukan muatan. Namun, panggilan GET dapat disertai dengan parameter string kueri dan nilainya untuk memfilter keluaran API. |
POST | /api/menu-items /api/orders | Berikut ini contoh muatan JSON untuk endpoint /api/menu-items untuk membuat sumber daya baru: { "title":"Beef Steak", "price": 5.50, "category":"main", } |
PUT | /api/menu-items/1 /api/orders/1 | Berikut ini contoh muatan JSON untuk endpoint /api/menu-items/1 untuk menggantikannya sepenuhnya. Perhatikan bahwa Anda perlu menyediakan semua data untuk permintaan PUT. { "title":"Chicken Steak", "price": 2.50, "category":"main", } |
PATCH | /api/menu-items/1 /api/orders/1 | Berikut ini contoh muatan JSON untuk titik akhir /api/menu-items/1 untuk memperbarui sebagian sumber daya ini { "price": 3.00 } |
DELETE | /api/menu-items /api/menu-items/1 /api/orders /api/orders/1 | Ketika panggilan DELETE dikirimkan ke titik akhir koleksi, seperti /api/menu-items, pengembang API harus menghapus seluruh koleksi. Ketika dikirim ke sumber daya tertentu, seperti ini, /api/menu-items/1, maka pengembang API harus menghapus sumber daya tersebut. |
Kode status
Mengirimkan kode status yang sesuai dengan setiap respons API sangat penting. Dan sebagai pengembang, Anda tidak boleh memilih sembarang kode. Setiap kode status memiliki arti, jadi Anda harus memilih kode yang paling tepat berdasarkan situasi. Berikut adalah daftar rentang kode status dan tujuannya.
Rentang kode status | Tujuan |
|---|---|
100-199 | Rentang ini terutama digunakan untuk menyampaikan beberapa informasi. Misalnya, terkadang API membutuhkan waktu untuk memproses permintaan dan tidak dapat langsung memberikan hasilnya. Dalam kasus seperti itu, pengembang API dapat mengaturnya untuk terus mengembalikan 102 – Processing hingga hasilnya siap. Dengan cara ini, klien memahami bahwa hasilnya belum siap dan harus diperiksa lagi. |
200-299 | Ini adalah kode keberhasilan. Jika klien meminta sesuatu dan API berhasil bertindak, API akan memberikan hasil dengan salah satu dari kode status ini. Misalnya, untuk panggilan PUT, PATCH, atau DELETE, Anda dapat mengembalikan 200 – Successful jika operasi berhasil. Untuk panggilan POST yang berhasil, Anda dapat mengaturnya untuk mengembalikan kode status 201 – Created ketika sumber daya berhasil dibuat. |
300-399 | Ini adalah kode pengalihan. Misalkan sebagai pengembang API, Anda mengubah titik akhir API dari /api/items to api/menu-items. Jika klien melakukan panggilan API ke /api/items, maka Anda dapat mengarahkan klien ke titik akhir baru ini /api/menu-items dengan kode status 301 – Permanently moved sehingga klien dapat melakukan panggilan baru ke titik akhir tersebut di lain waktu. |
400-499 | kode status 4xx digunakan dalam situasi berikut: jika klien meminta sesuatu yang tidak ada, mengirimkan muatan yang tidak valid dengan data yang tidak mencukupi, atau ingin melakukan tindakan yang tidak diotorisasi oleh klien. Untuk skenario di atas, kode status yang sesuai adalah: - 404 - Not Found jika klien meminta sesuatu yang tidak ada, - 400 - Bad Request jika klien mengirimkan muatan yang tidak valid dengan data yang tidak memadai, - 401 - Unauthorized, - 403 - Forbidden jika klien mencoba melakukan tindakan yang tidak diotorisasi. |
500-599 | Kode status yang mengkhawatirkan ini biasanya secara otomatis dibuat di sisi server jika terjadi kesalahan pada kode, dan pengembang API tidak menulis kode untuk menangani kesalahan tersebut. Misalnya, klien meminta sumber daya yang tidak ada, dan pengembang API mencoba menampilkan sumber daya tersebut tanpa memeriksa apakah sumber daya tersebut ada di database. Atau jika pengembang API tidak memvalidasi data yang masuk dan mencoba membuat sumber daya baru dengan data yang tidak valid atau tidak mencukupi. Anda, sebagai pengembang API, harus selalu menghindari kesalahan 5xx. |
Jenis respons
Saat ini, jenis respons yang paling umum digunakan dengan REST API adalah JSON, XML, teks biasa, dan terkadang YAML. Kerangka kerja seperti DRF dilengkapi dengan kelas penyaji bawaan yang dapat mengubah data ke dalam format yang sesuai dan menampilkannya dengan benar.
Ada juga renderer pihak ketiga yang tersedia untuk pekerjaan ini. Saat melakukan panggilan API, klien dapat menentukan format respons yang diinginkan dengan header HTTP Accept. Header tersebut harus dipertimbangkan untuk memberikan hasil dalam format tersebut dengan menggunakan kelas render. Berikut adalah daftar header HTTP untuk berbagai jenis respons.
Jenis respons | Header permintaan |
|---|---|
HTML | Accept: text/html |
JSON dan JSONP | Accept: application/json |
XML | Accept: application/xml Accept: text/xml |
YAML | Accept: application/yaml Accept: application/x-yaml Accept: text/yaml |
Kesimpulan
Dalam bacaan ini, Anda telah mempelajari berbagai jenis metode HTTP, kode status, dan jenis respons API.
There are no comments for now.