Latihan: Melakukan Permintaan HTTP

Latihan: Melakukan HTTP Request

Anda sudah mengetahui protokol HTTP dan format data yang ada di HTTP. Agar Anda tidak penasaran bentuk sebenarnya dari request dan response pada HTTP, mari kita coba membuat request pada web service kedai kopi melalui cURL.

cURL atau Client URL merupakan software berbasis command-line yang dapat melakukan transaksi data melalui beberapa protokol internet, salah satunya HTTP/S. cURL dapat diakses secara langsung tanpa proses install melalui Terminal (Linux dan Mac) atau CMD (Windows)[4].

Petama, bukalah CMD atau Terminal Anda.
Tuliskan perintah berikut ini.
```
curl -X GET https://coffee-api.dicoding.dev/coffees -i
```
curl adalah perintah untuk menggunakan program cURL pada Terminal atau CMD. -X GET adalah HTTP method/verb yang kita gunakan. https://coffee-api.dicoding.dev/coffees merupakan alamat request yang dituju. -i merupakan perintah untuk memberikan informasi detail terhadap response yang diberikan.

Kemudian, tekan enter.

Jika berhasil, Anda akan melihat hasil dari Web Server seperti berikut ini.

HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Tanggal: Sel, 27 Agu 2024 02:26:06 GMT
Content-Type: application/json; charset=utf-8
Panjang Konten: 188
Koneksi: tetap aktif
kebijakan-keamanan-konten: tingkatkan-permintaan-yang-tidak-aman
referrer-policy: strict-origin-when-cross-origin
opsi-bingkai-x: TOLAK
x-content-type-options: nosniff
perlindungan x-xss: 1; mode=blokir
bervariasi: asal
header-ekspos-kontrol-akses: WWW-Authenticate,Server-Authorization
kontrol cache: tanpa cache
rentang yang diterima: byte
{"message":"Berikut daftar kopi yang tersedia","coffees":[{"id":1,"name":"Kopi Tubruk","price":12000},{"id":2,"name":"Kopi Tarik","price":15000},{"id":3,"name":"Kopi Jawa","price":18000}]}

Mari kita bedah informasi apa saja yang ada pada contoh response di atas.

Status line
Status line berisi informasi versi dari HTTP seperti contoh di atas yaitu HTTP/1.1. Selain itu, juga terdapat informasi status code 200 dan status text OK.
HTTP Headers
HTTP Headers berisi informasi mengenai server yang menangani HTTP request. Dalam contoh di atas, server yang menanganinya adalah Server: nginx/1.18.0 (Ubuntu), tanggal response dilakukan pada Date: Tue, 27 Aug 2024 02:26:06 GMT, dan tipe konten atau format konten yang digunakan yakni Content-Type: application/json; charset=utf-8.
Message Body
Message body berisi informasi yang dibutuhkan client seperti resources. Pada contoh di atas, message body berisi daftar kopi yang tersedia.

Selamat! Anda berhasil melakukan HTTP Request pertama! Tetap semangat ya karena selanjutnya kita akan mendalami protokol HTTP.

Menyelami Protokol HTTP

Masih ingat, kan, bahwa RESTful API menggunakan protokol HTTP? Anda mungkin penasaran bagaimana cara menggunakannya.

Anda sudah mengetahui pola komunikasi client dengan server. Berikutnya timbul pertanyaan, bagaimana cara server mengidentifikasi request yang masuk pada RESTful API? Misalnya, request untuk mendapatkan data dan request untuk menambahkan data. Tenang, di protokol HTTP terdapat HTTP Method/Verbs. HTTP method/verbs adalah cara client untuk memberitahukan server apa yang harus dilakukan terhadap resources. Berikut beberapa method/verbs yang umum digunakan di HTTP.

GET untuk mendapatkan data.
POST untuk menambahkan data.
PUT untuk mengupdate data.
PATCH untuk mengupdate sebagian data.
DELETE untuk menghapus data.

Setiap request yang diproses oleh server tidak semuanya berhasil, ada kalanya request tersebut gagal diproses. Bagaimana cara server untuk memberitahu client bahwa request yang dijalankan sukses atau gagal? Server melakukannya dengan cara melampirkan status code di response.

Status code yang diberikan oleh server memiliki arti tertentu, status code untuk request yang berhasil berbeda dengan yang gagal. Status code terdiri dari 3 digit angka. Berikut nilai-nilai status code yang sering digunakan.

200 (OK) - Permintaan client berhasil dijalankan oleh server.
201 (Created) - Server berhasil membuat/menambahkan resource yang diminta client.
400 (Bad Request) - Permintaan client gagal dijalankan karena proses validasi input dari client gagal.
401 (Unauthorized) - Permintaan client gagal dijalankan. Biasanya ini disebabkan karena pengguna belum melakukan proses autentikasi.
403 (Forbidden) - Permintaan client gagal dijalankan karena ia tidak memiliki hak akses ke resource yang diminta.
404 (Not Found) - Permintaan client gagal dijalankan karena resource yang diminta tidak ditemukan.
500 (Internal Server Error) - Permintaan client gagal dijalankan karena server mengalami error (membangkitkan Exception).
503 (Service Unavailable) - Permintaan client gagal dijalankan karena server tidak dapat menangani permintaan.

Perlu diingat bahwa status code yang diberikan oleh server haruslah tepat. Penggunaan status code yang tepat dapat meminimalisasi kebingungan dan kesalahpahaman dengan client.

Latihan: Eksplorasi Metode HTTP

Pada latihan sebelumnya, Anda sudah berhasil melakukan HTTP Request. Seperti yang Anda ketahui, HTTP memiliki beberapa metode/kata kerja seperti POST. Nah, pada latihan ini, Anda akan mencoba membuat HTTP Request dengan metode POST melalui cURL . Yuk, simak latihannya!

Petama, bukalah CMD atau Terminal Anda.
Tuliskan perintah berikut ini.
```
curl -X POST -H "Content-Type: application/json" -d " { \"name\": \"Kopi Tubruk\"} " https://coffee-api.dicoding.dev/transactions -i 
```
Jika sebelumnya menggunakan metode HTTP/kata kerja GET, sekarang Anda akan menggunakan metode HTTP/kata kerja POST. Untuk alamat request-nya, yaitu https://coffee-api.dicoding.dev/transactions . Perintah -i juga kami tambahkan untuk memberikan informasi detail terhadap respon yang diberikan.

Selanjutnya tekan Enter. Anda akan melihat hasil dari Web Server seperti berikut ini.

HTTP / 1.1 201 Dibuat  
Server : nginx / 1.18.0 ( Ubuntu ) 
Tanggal : Sel , 27 Agu 2024 04 : 05 : 31 GMT     
Content - Type : application / json ; charset = utf - 8
Panjang Konten : 46  
Koneksi : tetap aktif
kebijakan - keamanan - konten : tingkatkan - permintaan - yang - tidak - aman
referrer - policy : strict - origin - when - cross - origin
opsi - bingkai - x : TOLAK
x - content - type - options : nosniff
perlindungan x - xss : 1 ; modus = diblokir 
bervariasi : asal
header - ekspos - kontrol - akses : WWW - Otentikasi , Server - Otorisasi
kontrol cache : tanpa cache
{ "message" : "Pesanan berhasil!" , "sukses" : benar }

Anda pasti sudah bisa membaca respon-nya kan? Sebenarnya tidak berbeda jauh dengan respon yang diberikan oleh metode HTTP/kata kerja GET.

Perbedaannya terlihat pada kode status. Jika sebelumnya kode status bernilai 200, sekarang kode status bernilai 201 (artinya sumber daya berhasil ditambahkan yakni memesan kopi tubruk). Selain kode status, perbedaan lainnya terdapat pada badan pesan. Jika sebelumnya daftar berisi kopi, sekarang message body hanya berisi pesan “Pesanan berhasil!”.

Keren, sekarang Anda sudah berhasil melakukan HTTP request dengan method/verbs POST. Untuk metode lainnya seperti PUT dan DELETE, format request dan respon-nya tidak berbeda jauh dengan contoh yang telah kita lakukan.

Merancang URL dengan Baik

Sebelumnya, Anda sudah mencoba mengakses URL dengan method GET dan POST. Namun, tahukah Anda apa itu URL? Agar tidak penasaran, yuk kita bahas.

URL (Uniform Resources Locator) adalah alamat resources yang unik di internet. URL adalah salah satu cara untuk mengambil resources yang digunakan melalui Browser. Masih ingatkah Anda di contoh sebelumnya kita mengambil resources berupa daftar kopi? Kita meminta daftar kopi dengan melakukan HTTP request dan menuliskan URL-nya.

URL terbentuk dari beberapa bagian, ada bagian yang wajib dan opsional. Bagian pertama yang membentuk URL adalah scheme, berikutnya nama domain, dan path. Untuk bagian opsional yang membentuk URL adalah port, query parameter (akan dibahas di modul berikutnya).

Mari kita coba lihat contoh URL lainnya, misalnya https://www.dicoding.com/learningpaths/41. URL tersebut digunakan untuk melihat detail learning path Back-End. Jika dibedah, URL tersebut menggunakan scheme protokol HTTPS, nama domainnya adalah dicoding.com, dan path-nya adalah learningpaths/41.

Karena resources diwakili oleh URL dan URL itu sendiri ditangani oleh Web Server, URL untuk setiap resources bisa berbeda dan tergantung kepada pembuat Web Server sehingga URL akan berbeda di setiap Web Server.

Penting untuk mendesain URL dengan baik. Kita perlu untuk mengikuti aturan umum (convention) dalam mendesain URL agar penggunaan API kita menjadi lebih mudah. URL yang dirancang dengan baik membuat Front-End Developer atau developer lainnya yang mengonsumsi RESTful API kita menjadi bahagia karena URL sudah sesuai aturan umum yang ada.

Lalu, seperti apa convention dalam merancang URL?

Menggunakan Kata Benda untuk Mewakili Resources

Jangan pernah menggunakan kata kerja pada path URL, sebaiknya gunakanlah kata benda.

Alasannya adalah karena kata kerja seperti mendapatkan, menambah, dan menghapus data sudah terwakili oleh HTTP Method/Verbs. Karena kata kerja sudah terwakili secara jelas melalui HTTP Verb, kita tidak perlu lagi menambahkan kata kerja di path URL.

Anda cukup memberikan endpoint GET /products untuk mendapatkan daftar produk atau POST /products untuk menambahkan produk. Berikut contoh yang disarankan.

Menggunakan Kata Jamak pada Endpoint untuk Resource Collection

Gunakanlah kata jamak jika memungkinkan, kecuali untuk resources yang tunggal. Alasan menggunakan kata jamak adalah karena jarang sekali data yang disimpan berjumlah satu. Dengan menggunakan kata jamak, path yang ditulis akan konsisten dengan database (database memiliki lebih dari satu record/data).

Menggunakan Tanda Hubung (-)

Untuk meningkatkan keterbacaan URL, gunakanlah tanda hubung. Perhatikan contoh URL tanpa tanda hubung berikut: https://www.example.com/categories/machinelearning/practices. URL tersebut lebih sulit dibaca, kan?

Kemudian, bandingkan dengan URL yang menggunakan tanda hubung berikut: https://www.example.com/categories/machine-learning/practices.

Jangan Pernah Menambahkan Ekstensi File di URL

Menambahkan ekstensi seperti .html, .json, dan .xml di URL hanya akan membuat URL lebih panjang dan tidak memberikan manfaat apa pun. Oleh karena itu, jangan menuliskan ekstensi file di URL.

Itulah beberapa aturan standar dalam mendesain URL untuk RESTful API. Apakah ketika tidak menerapkan standar ini menyebabkan RESTful API kita error? Jawabannya adalah tidak. Ini hanya aturan standar yang banyak diikuti oleh developer di luar sana. Jika tidak ingin mengikutinya, tidak akan menyebabkan RESTful API error, tetapi akan menyulitkan kolaborasi dan pengguna kesulitan ketika ingin mengaksesnya.