Apa itu API

API adalah cara sebuah program meminta sesuatu dari program lain. Namanya kependekan dari application programming interface, yang tidak banyak menjelaskan. Dalam praktiknya, dan di sepanjang tutorial ini, API adalah server yang menjawab request dengan data, bukan dengan halaman web.

Aplikasi cuaca di ponsel Anda tidak menyimpan prakiraan. Saat dibuka, aplikasi itu mengirim request ke sebuah server di suatu tempat, menerima beberapa kilobyte data suhu dan kecepatan angin, lalu menggambarnya di layar. Bagian servernya adalah API. Aplikasinya adalah salah satu kliennya.

Request pertama Anda

Tempel alamat ini di bilah alamat browser Anda lalu tekan Enter:

https://api.testingapis.com/api/Products/1

Anda akan menerima sesuatu seperti ini:

{
  "id": 1,
  "title": "Wireless Noise-Cancelling Headphones",
  "price": 249.99,
  "description": "Over-ear headphones with 30hr battery life and active noise cancellation.",
  "category": "electronics",
  "image": "https://picsum.photos/seed/prod1/400/400",
  "rating": { "rate": 4.3, "count": 127 },
  "inStock": true,
  "createdAt": "2025-06-12T10:30:00Z"
}

Browser Anda mengirim request ke sebuah server. Server mencari produk nomor 1 dan mengirim kembali deskripsinya. Pertukaran itu, satu request dan satu response, adalah inti dari setiap interaksi dengan API. Sisa tutorial ini membahas detail pertukaran itu dan cara memeriksa bahwa server menanganinya dengan benar.

Anda juga bisa mengirim request dari halaman ini. Tombol Kirim di bawah melakukan hal yang sama dengan yang baru saja dilakukan browser Anda, dan menampilkan status response di atas body-nya. Anda akan melihat tombol ini di sepanjang pelajaran.

Klien dan server

Program yang mengirim request adalah klien. Program yang menjawab adalah server. Klien bisa berupa browser, aplikasi ponsel, server lain, alat baris perintah, atau tes yang Anda tulis. Server tidak bisa membedakan mereka, dan memang tidak perlu. Ia membaca request, mengerjakan tugasnya, lalu membalas.

Ini penting untuk pengujian. Karena server memperlakukan setiap klien dengan cara yang sama, Anda bisa mengujinya tanpa aplikasi yang biasanya berbicara dengannya. Anda tidak perlu menelusuri lima layar aplikasi belanja untuk melihat apakah harga produk benar. Anda meminta produk itu ke API dan melihat harganya.

Endpoint

Alamat yang Anda buka terdiri dari dua bagian. https://api.testingapis.com adalah base URL: ia menyebut server mana yang diajak bicara. /api/Products/1 adalah path: ia menyebut apa yang Anda inginkan dari server itu. Setiap path yang dipahami server disebut endpoint. API ini punya beberapa ratus. Beberapa contoh:

Endpoint apa saja yang ada bisa Anda ketahui dari dokumentasi API. Untuk API ini, itu adalah referensi API. Proyek sungguhan sangat beragam dalam hal ini. Ada yang dokumentasinya rapi, ada yang punya file OpenAPI yang dibuat dari kode, dan ada yang hanya berupa pesan di kanal chat dari developer yang menulisnya. Sebagian dari pekerjaan penguji adalah menyadari kapan dokumentasi dan API tidak sejalan.

Saat jawabannya tidak

Sekarang minta produk yang tidak ada:

Server membalas:

{
  "status": 404,
  "error": "Not Found",
  "message": "Product with ID 9999 does not exist."
}

Ini juga response yang benar. Produk 9999 tidak ada, dan server mengatakannya dengan jelas: status 404, yang berarti "tidak ditemukan", dan pesan yang menjelaskan ID mana yang tidak ada. API yang baik sama telitinya terhadap request yang tidak bisa dipenuhinya seperti terhadap yang bisa. Banyak pengujian API terjadi di sini, di jalur yang tidak mulus, karena di situlah developer paling sedikit menghabiskan waktu dan di situlah sebagian besar bug berada.

Mengapa menguji di level API

Anda bisa menguji semuanya lewat layar aplikasi. Tim menguji API secara langsung karena beberapa alasan praktis.

• Lebih cepat. Sebuah request butuh milidetik. Mengeklik antarmuka sampai ke keadaan yang sama butuh detik, dan mengotomatiskan klik-klik itu jauh lebih lama ditulis serta rusak setiap kali sebuah tombol berpindah.
• API biasanya ada lebih dulu. Backend dan frontend sering dibangun bersamaan, jadi Anda bisa mulai menguji backend sebelum ada apa pun untuk diklik.
• Antarmuka menyembunyikan masalah. Misalnya kolom jumlah di aplikasi belanja hanya menerima angka 1 sampai 10. API di baliknya menerima request biasa, dan siapa pun bisa mengirim request dengan jumlah -5. Jika server percaya aplikasi sudah memeriksanya, pesanan itu lolos dengan total negatif. Anda hanya menemukannya dengan berbicara langsung ke API.
• Satu API sering melayani beberapa klien: situs web, aplikasi iPhone, aplikasi Android, integrasi mitra. Bug di API adalah bug di semuanya.

Pengujian antarmuka tetap punya tempatnya. Itulah satu-satunya cara memeriksa bahwa layar-layarnya berfungsi. Tetapi aturan sistem (siapa boleh melihat apa, seperti apa pesanan yang valid, apa yang terjadi saat stok habis) berada di API, jadi di sanalah Anda memeriksanya.