Cara Praktis Menguji API

Ibarat warung makan yang nyediain menu buat pelanggan. Nah, API testing tuh ngecek apakah warungnya beneran ngasih makanan sesuai pesanan atau malah zonk. Yuk, kita bahas cara yang sering dipakai untuk testing API.

HTTP Methods: Cara Ngomong Sama API

HTTP Methods itu kayak gaya komunikasi kita ke API. Nih beberapa yang paling sering dipakai:

• GET → Buat ngambil data. Contoh: “Bro, kasih daftar user dong?”
• POST → Buat nambah data baru. Contoh: “Tambah user ini ke sistem ya.”
• PUT → Buat update data keseluruhan. Contoh: “Update semua info user ini.”
• PATCH → Buat update data sebagian aja. Contoh: “Cuman ganti nama user ini ya.”
• DELETE → Buat hapus data. Contoh: “User ini udah ga perlu, hapus aja.”

🔍 Cara ngetestnya:

• Pastiin API bener-bener merespons sesuai ekspektasi tiap metode.
• Cek kalau data yang dikirim emang masuk ke database atau berubah sesuai permintaan.

HTTP Status Codes: Jawaban dari API

Status code itu kayak cara API bilang “Oke”, “Gagal”, atau “Apaan sih?”.

• 2xx (Success) → Semua lancar jaya! 200 OK → Permintaan sukses, 201 Created → Data berhasil ditambahkan.
• 4xx (Client Error) → Kesalahan dari sisi pengguna, 400 Bad Request → Request ada yang salah formatnya. 401 Unauthorized → Ga boleh masuk, belum login. 404 Not Found → API-nya ga nemu jalan.
• 5xx (Server Error) → Kesalahan di backend API. 500 Internal Server Error → Ada yang jebol di server.

🔍 Cara ngetestnya:

• Pastikan API ngasih status code yang sesuai.
• Coba kirim request aneh-aneh buat lihat error handlingnya.

Authentication & Authorization: Siapa aja yang Boleh Masuk?

Gak semua orang bisa asal akses API. Ada 2 hal penting di sini:

• Authentication (Autentikasi) → “Siapa lu?”. Contohnya pake API Key, JWT Token, atau OAuth.
• Authorization (Otorisasi) → “Lu boleh ngapain aja?”. Contohnya user biasa ga boleh ngapus data admin.

🔍 Cara ngetestnya:

• Coba request tanpa token, harusnya ditolak.
• Coba pake token user biasa buat akses fitur admin, harusnya ga bisa.

Headers: Informasi Tambahan di Request

Headers tuh kayak embel-embel tambahan di surat yang kita kirim ke API.

• Content-Type → Format data (application/json, text/plain, dll).
• Authorization → Token buat autentikasi.
• Accept-Language → Bahasa yang diminta.

🔍 Cara ngetestnya:

• Coba request tanpa header, apakah API tetap jalan?
• Kirim Content-Type yang salah, API harusnya nolak.

Path & Query Parameters: Ngasih Instruksi ke API

Ada dua cara buat kasih detail tambahan ke API:

• Path Parameters → Bagian dari URL, contoh:

GET /users/123

Artinya ambil user dengan ID 123.

• Query Parameters → Tambahan di URL setelah ?, contoh:

GET /users?role=admin&active=true

Artinya ambil semua user yang role-nya admin dan masih aktif.

🔍 Cara ngetestnya:

• Coba kirim request dengan parameter yang salah, harusnya API nolak.
• Pastikan API ngasih data yang sesuai sama parameter yang dikirim.

Versioning: API Jangan Sampai Bentrok!

Kadang API berkembang, tapi versi lama masih dipakai. Solusinya? Versioning!

• Bisa pake Path: /v1/users, /v2/users
• Bisa pake Headers: Accept: application/vnd.myapi.v2+json

🔍 Cara ngetestnya:

• Pastikan versi API yang beda beneran kasih respons yang beda.
• Cek apakah API lama masih bisa jalan tanpa error.

Pagination: Biar API Gak Kelebihan Beban

Kalau ada 100 ribu data, masa iya semuanya ditampilkan sekaligus? Makanya ada pagination buat batasi jumlah data yang diambil per request.

Contoh:

GET /users?page=2&limit=10

Artinya ambil halaman kedua, masing-masing 10 user per halaman.

🔍 Cara ngetestnya:

• Pastikan pagination bekerja sesuai permintaan (limit, page)

Input Payload Validation: Data Masuk Harus Benar

Kita harus pastikan API terima data yang bener sebelum diproses.

Contoh input valid:

{
  "name": "Budi",
  "email": "budi@example.com"
}

Contoh input gak valid:

{
  "name": "",
  "email": "budi@"
}

Harusnya API nolak data yang gak valid!

🔍 Cara ngetestnya:

• Kirim data yang kurang, API harus nolak.
• Coba input aneh-aneh (script injection, SQL injection), API harus aman.

Response Payload Validation: Data Keluar Harus Bener

API harus kasih data dengan format yang bener.

Contoh respons valid:

{
  "id": 1,
  "name": "Budi",
  "email": "budi@example.com"
}

Kalau tiba-tiba name ilang atau email kosong, berarti ada yang salah!

🔍 Cara ngetestnya:

• Cek apakah semua field yang dibutuhkan ada di respons API.
• Pastikan API gak bocorin data sensitif (misal password).

Error Handling: Biar API Gak Malfunction

API yang baik harus kasih error yang jelas.

• Error yang cakep:

{  "error": "User not found", "code": 404 }

• Error yang jelek:

{ "message": "Something went wrong"}

Kenapa Error “Something went wrong” ini dianggap jelek? karena tidak informatif dan tidak membantu debugging. Biasanya akan lumayan membingungkan sisi user atau pun tester terkait apa yang salah dari endpoint tersebut?, Kenapa error tersebut muncul?, dan Apakah masalahnya dari server atau request user?.

🔍 Cara ngetestnya:

• Coba request dengan data salah, API harus kasih pesan error yang jelas.
• Pastikan API gak kasih error 500 kalau cuma ada typo di request.

happytesting!