-: Summary | Lajulabs LMS

2.7 Konsep Dasar API

Di balik setiap aplikasi yang kita gunakan sehari-hari, seperti mobile banking, layanan transportasi online, marketplace, hingga media sosial, terdapat “jembatan tak terlihat” yang menghubungkan antar sistem dan membuat semuanya berjalan lancar. Jembatan inilah yang disebut dengan API (Application Programming Interface).

API memungkinkan komunikasi antara dua aplikasi atau layanan, layaknya seorang penerjemah yang menjembatani dua orang yang berbicara bahasa berbeda. Misalnya, saat kamu membuka aplikasi cuaca dan melihat prakiraan hari ini, aplikasi tersebut sebenarnya sedang "berbicara" dengan server pihak ketiga untuk mengambil data cuaca terbaru menggunakan API.

Dalam konteks pengujian perangkat lunak, pemahaman tentang API sangat penting. API adalah titik interaksi utama antar sistem atau komponen dalam aplikasi. Jika API tidak berfungsi sebagaimana mestinya, maka seluruh alur kerja pengguna bisa terganggu meskipun tampilan antarmuka terlihat baik.

Sebagai QA Engineer, memahami bagaimana API bekerja akan membantumu:

● Menemukan bug lebih awal sebelum sampai ke UI.

● Melakukan automation testing lebih cepat dan efisien.

● Menguji logika dan integrasi aplikasi secara mendalam.

Topik ini akan membekalimu dengan pemahaman dasar tentang cara kerja API, jenis-jenis API, dan bagaimana QA dapat berperan dalam menguji API secara efektif. Sebelum memulai pembelajaran pada topik ini, mari luangkan waktu sejenak untuk merefleksikan poin-poin berikut:

Kalau kamu pernah pakai dua aplikasi berbeda yang saling terhubung, misalnya login ke e-commerce pakai akun Google, menurutmu bagaimana cara dua sistem itu bisa 'berbicara'?

Pernahkah kamu menguji aplikasi yang UI-nya berjalan lancar, tapi ternyata datanya tidak sesuai? Menurutmu, kenapa bisa terjadi?

Digiers, sebelum memulai pembelajaran, mari kita pahami terlebih dahulu capaian yang ingin diraih dalam topik ini. Berikut adalah tujuan pembelajaran yang menjadi panduan dalam proses belajar:

● Mendeskripsikan perbedaan antara REST dan SOAP dalam arsitektur API.

● Menganalisis simulasi REST API untuk pengambilan data transaksi pada platform e-commerce.

2.7.1 Arsitektur API: Perbandingan REST dan SOAP

Ketika dua sistem berbeda saling berkomunikasi, misalnya, aplikasi mobile dengan server, atau sistem pembayaran dengan bank, mereka membutuhkan sebuah perantara atau “bahasa” yang bisa dipahami bersama. Di dunia software, perantara ini dikenal sebagai API (Application Programming Interface). API bukan hanya sekedar jalur komunikasi; ia adalah pondasi penting yang memungkinkan aplikasi modern terintegrasi dengan berbagai layanan.

Namun, tidak semua API dibuat dengan cara yang sama. Selama dua dekade terakhir, dua pendekatan utama telah mendominasi cara API dirancang dan digunakan: REST (Representational State Transfer) dan SOAP (Simple Object Access Protocol).

⬛ REST: Modern, Ringan, dan Fleksibel

REST pertama kali diperkenalkan oleh Roy Fielding pada tahun 2000 sebagai bagian dari disertasi doktoralnya. REST bukan protokol, melainkan arsitektur yang dibangun di atas protokol HTTP yang sudah umum digunakan di internet. Pendekatan ini menjadi sangat populer karena sifatnya yang stateless, ringan, dan mudah digunakan di lingkungan web dan mobile.

Cara Kerja REST API

Pada dasarnya, cara kerja REST API mirip seperti saat kita menjelajahi internet menggunakan browser. Ketika kita mengetik alamat web atau mengklik tautan, browser akan menghubungi server untuk meminta halaman tertentu. Demikian pula, dalam sistem REST API, klien (biasanya berupa frontend seperti aplikasi mobile atau website) akan menghubungi server untuk meminta sumber daya (resource), seperti data pengguna, daftar produk, atau riwayat transaksi.

Agar komunikasi antara klien dan server ini berjalan dengan benar, developer API akan menyediakan dokumentasi API, yaitu petunjuk teknis yang menjelaskan:

● Alamat (endpoint) apa yang bisa diakses,

● Metode HTTP apa yang digunakan (GET, POST, dll),

● Data apa yang harus dikirim,

● Format response yang akan diterima.

Alur Umum Kerja REST API

Berikut ini adalah tahapan standar dalam proses request–response REST API:

1. **Klien mengirim permintaan (request)**
Klien merujuk ke dokumentasi API untuk mengetahui bagaimana cara menyusun request yang benar, misalnya, ke endpoint mana, metode HTTP apa yang digunakan (GET, POST, PUT, DELETE), serta apakah perlu menyertakan data atau parameter.

2. Server melakukan autentikasi
Server akan memeriksa apakah klien yang mengirim permintaan memiliki hak akses yang sah. Biasanya, ini dilakukan melalui token otentikasi (seperti JWT atau Bearer Token).

3. Server memproses permintaan
Setelah lolos autentikasi, server akan memproses request. Ini bisa mencakup pencarian data di database, pemrosesan logika bisnis, atau validasi data.

4. Server mengirim response
Server akan mengembalikan response kepada klien, yang biasanya berisi:

○ Status dari permintaan (berhasil atau gagal),

○ Data yang diminta (jika ada),

○ Atau pesan kesalahan jika terjadi error.

Gambar 2.7.1 Alur Kerja REST API

Komponen REST API

API Request

● Endpoint URL: Dalam layanan REST, identifikasi sumber daya ini umumnya dilakukan melalui URL (Uniform Resource Locator). URL menunjukkan jalur atau lokasi sumber daya yang dimaksud. Secara sederhana, URL ini mirip seperti alamat situs web yang biasa kamu ketik di browser saat ingin membuka halaman tertentu. URL juga dikenal sebagai endpoint permintaan, dan berfungsi untuk memberi tahu server secara spesifik apa yang dibutuhkan oleh client (pengguna atau aplikasi pemanggil). Contoh:

○ https://api.example.com/users/123/profile → Mengambil data profil pengguna dengan ID 123

Struktur URL

Gambar 2.7.2 Struktur URL

Sumber Gambar: GeeksforGeeks

Scheme (Skema) → Bagian awal URL (misalnya https://) yang menunjukkan aturan/protokol untuk mengirim dan menerima data.
Subdomain → Bagian tambahan di depan domain (misalnya www) yang memisahkan bagian situs.
Domain Name → Nama utama situs (misalnya google di google.com).
Top-level Domain (TLD) → Akhiran domain (misalnya .com, .org) yang menunjukkan jenis atau lokasi situs.
Port Number → Nomor yang menunjukkan layanan tertentu di server (misalnya 80 untuk HTTP, 443 untuk HTTPS).

● HTTP (Hypertext Transfer Protocol) → Protokol standar untuk mengirim dan menerima data di web, namun tidak menggunakan enkripsi, sehingga data bisa dibaca pihak ketiga jika disadap.

● HTTPS (Hypertext Transfer Protocol Secure) → Versi aman dari HTTP yang menggunakan enkripsi SSL/TLS untuk melindungi data saat ditransfer, sehingga lebih aman terutama untuk login, transaksi, dan data sensitif.

Path → Jalur menuju halaman atau file tertentu di situs.
Query String Separator → Tanda ? yang memisahkan alamat utama dengan data pencarian atau parameter.
Query String → Data atau parameter tambahan setelah tanda ? untuk permintaan khusus ke situs.
Fragment → Bagian setelah # yang menunjuk ke lokasi tertentu di dalam halaman.

Path dan Query String keduanya merupakan jenis parameter pada URL.

● Path parameter: jalur menuju halaman atau file tertentu, biasanya untuk identifikasi resource. Contoh: GET /users/101/orders/20 → Mengakses pesanan ke-20 dari user dengan ID 101.

● Query parameter: pasangan key-value yang ditambahkan di akhir URL untuk mengirimkan data tambahan ke server. Biasanya digunakan untuk melakukan filtering, sorting, pagination, atau mengirimkan informasi tertentu tanpa mengubah struktur path utama URL.
Contoh: GET /transactions?status=paid&limit=10 → Mengambil maksimal 10 transaksi yang statusnya sudah dibayar.

KEY	VALUE
status	paid
limit	10

Selain path parameter dan query parameter, ada juga jenis parameter lain namun tidak berada di URL, yaitu cookie parameter. Letaknya pada HTTP Header, yang berfungsi menyimpan informasi sesi atau preferensi user di browser, lalu dikirim otomatis ke server pada setiap request ke domain yang sama.

● HTTP Methods: REST memanfaatkan metode HTTP standar:

○ GET
GET dipakai untuk mengambil atau melihat data dari server. Misalnya kamu mau lihat daftar transaksi, kamu tinggal kirim permintaan GET ke server.

Contoh:
GET https://api.example.com/users/123

● HTTP Methods: GET→ membaca/mengambil data dari server.

● Path: /users/123 → endpoint untuk mengambil data pengguna dengan ID 123.

● Body: tidak ada (GET biasanya tidak mengirim body).

○ POST
POST dipakai untuk mengirim data baru ke server, misalnya membuat pesanan baru atau entri baru.

Contoh:
POST https://api.example.com/orders

● HTTP Methods: POST → mengirim data baru ke server.

● Path: /orders → endpoint untuk membuat pesanan baru.

● Body: berisi detail pesanan (misalnya produk, jumlah, harga), yang akan menambahkan pesanan baru ke sistem setiap kali permintaan dikirim.
{

"produk": "Laptop",

"jumlah": 1

}

○ PUT
PUT digunakan untuk memperbarui (mengganti) data yang sudah ada pada server. Berbeda dari POST, permintaan PUT bersifat idempotent, artinya jika dikirim berkali-kali dengan isi yang sama, hasilnya akan tetap sama, data akan diperbarui ke kondisi tertentu.

Contoh:
PUT https://api.example.com/products/1001

● HTTP Methods: PUT→ memperbarui data secara keseluruhan.

● Path: /products/1001 → endpoint untuk memperbarui informasi produk dengan ID 1001.

● Body: berisi data lengkap yang diperbarui (misalnya produk, stok).
{

"produk": "Laptop",

"stok": 5

}

○ DELETE
DELETE digunakan untuk menghapus sumber daya dari server. Aksi ini akan mengubah kondisi server karena data yang dihapus tidak lagi tersedia. Namun, jika pengguna tidak memiliki izin akses yang sah (autentikasi/autorisasi), maka permintaan penghapusan akan ditolak.

Contoh:
DELETE https://api.example.com/users/789

● HTTP Methods: DELETE→ menghapus data.

● Path: /users/789 → endpoint untuk menghapus data pengguna dengan ID 789

● Body: biasanya tidak ada (data dihapus berdasarkan path).

● HTTP Headers

Header pada permintaan HTTP merupakan metadata yang dikirim oleh klien (seperti browser atau aplikasi) kepada server dan sebaliknya. Header ini memberikan informasi tambahan yang penting bagi komunikasi, seperti:

Format konten yang dikirim atau diharapkan (Content-Type, Accept),

Informasi autentikasi (Authorization),

Status koneksi, bahasa, encoding, dan lainnya.

Contoh Header:

Content-Type: application/json

Accept: application/json

Authorization: Bearer abc123token

● Request Body

Request Body adalah bagian dari permintaan HTTP yang berisi data yang ingin kita kirim ke server.

● Umumnya digunakan pada metode POST, PUT, dan PATCH untuk mengirim data baru atau memperbarui data.

● Format data mengikuti Content-Type yang ditentukan di header (misalnya application/json untuk JSON).

Contoh body JSON dalam request POST:

{

"userId": 101,

"amount": 250000,

"status": "pending"

}

API Response

● Status Code: Setiap request diikuti response dari server lengkap dengan status code.

Berikut response code yang paling umum dijumpai:

Status Code	Nama	Keterangan
200	OK	Permintaan berhasil
301	Permanent Redirect	Resource dipindahkan permanen ke URL baru
302	Temporary Redirect	Redirect sementara ke URL lain
400	Bad Request	Permintaan salah format atau parameter tidak valid
401	Unauthorized	Memerlukan autentikasi pengguna / kredensial tidak valid
403	Forbidden	Server memahami permintaan tetapi permintaan ditolak
404	Not Found	Resource tidak ditemukan
500	Internal Server Error	Server mengalami kesalahan tak terduga
502	Bad Gateway	Server perantara menerima respon tidak valid dari server tujuan
503	Service Unavailable	Server sedang down atau maintenance
504	Gateway Timeout	Server belum menerima respons tepat waktu

● Response Body: Berisi data yang diterima dari server setelah memproses request, biasanya dalam format JSON.

JSON adalah format pertukaran data yang ringan, mudah dibaca manusia, dan mudah diproses komputer. Banyak digunakan di API sebagai format request body maupun response body.

Isi JSON terdiri dari pasangan key dan value:

● Key → selalu berupa teks (string) dan ditulis di dalam tanda kutip ".

● Value → bisa berupa:

1. String → "John"

2. Number → 25

3. Boolean → true / false

4. Array → ["A", "B", "C"]

5. Object → {"id": 1, "name": "Item"}

6. null → null

Contoh Response Body

{

"userId": 101,

"name": "John Doe",

"roles": ["admin", "editor"],

"profile": {

"age": 30,

"email": "john@example.com"

}

Cara mengambil value dari Response Body (JSON):

Untuk mengambil data, gunakan nama key untuk mengambil nilainya. Jika value berupa array, gunakan indeks (dimulai dari 0). Jika value berupa object di dalam object, gunakan tanda titik (.) untuk mengaksesnya.

● userId → 101 (mengambil value key userId )

● roles[0] → "admin" (mengambil value pertama dari array roles)

● profile.email → "john@example.com” (mengambil value dari key email di dalam object profile)

⬛ Metode Autentikasi pada REST API

Sebelum server mengirimkan data melalui REST API, autentikasi harus dilakukan terlebih dahulu untuk memastikan bahwa permintaan (request) datang dari pengguna atau sistem yang memiliki hak akses yang sah.

Sama seperti saat kita menunjukkan KTP atau SIM untuk membuktikan identitas kita dalam kehidupan nyata, dalam REST API pun klien (client) harus membuktikan identitasnya kepada server agar dapat dipercaya dan mendapatkan akses ke resource yang diminta.

Mengapa Autentikasi Penting?

● Mencegah akses tidak sah ke data sensitif (seperti data transaksi atau informasi pelanggan),

● Memberi kontrol siapa yang boleh mengakses apa,

● Menjaga integritas dan keamanan sistem backend.

Jenis-Jenis Metode Autentikasi pada REST API

1. HTTP Authentication

Metode autentikasi ini sudah menjadi bagian dari standar protokol HTTP, dan terdiri dari dua skema populer:

a. Basic Authentication

● Klien mengirim username dan password melalui header dalam request.

● Informasi ini di-encode menggunakan Base64, yaitu metode pengkodean yang mengubah teks menjadi kombinasi 64 karakter agar aman ditransmisikan.

● Contoh penggunaan: cocok untuk sistem internal atau API testing di lingkungan terbatas, tapi tidak aman jika tanpa protokol HTTPS.

b. Bearer Token **(Token-Based Authentication)**

● Server memberikan sebuah token saat pengguna berhasil login.

● Token tersebut disimpan klien, dan digunakan dalam setiap request berikutnya melalui Authorization: Bearer <token>.

● Token biasanya berupa string acak yang sudah dienkripsi.

● Lebih aman dibanding basic auth karena password tidak dikirim setiap saat.

2. API Key

● Server menghasilkan API key unik untuk setiap klien saat pertama kali mendaftar.

● API key digunakan dalam setiap request sebagai tanda pengenal.

● Biasanya dikirim lewat header (x-api-key) atau sebagai parameter query.

● Kelemahan: rentan terhadap pencurian jika tidak dienkripsi atau dikirim lewat HTTP biasa.

**3. OAuth (Open Authorization)**

● Merupakan metode autentikasi paling aman dan fleksibel.

● Menggunakan kombinasi password dan token akses, dan sering digunakan oleh layanan besar seperti Google, Facebook, atau GitHub.

● Terdiri dari dua langkah:

1. Klien melakukan login menggunakan username dan password → server memberikan token.

2. Token ini digunakan untuk permintaan selanjutnya, dan bisa memiliki jangka waktu, ruang lingkup akses (scope), dan bisa dicabut kapan saja.

● Cocok untuk sistem yang butuh kontrol akses yang kompleks.

REST sangat cocok untuk aplikasi modern yang bersifat real-time dan terus berkembang, seperti:

● Aplikasi e-commerce

● Media sosial

● Aplikasi keuangan digital

● Layanan SaaS dan cloud API

Contoh: Aplikasi Survei

● GET /surveys → ambil semua survei

● POST /surveys → buat survei baru

● GET /surveys/123 → ambil detail survei dengan ID 123

● POST /surveys/123/responses → kirim tanggapan survei

⬛ SOAP: Formal, Terstruktur, dan Enterprise-grade

Sebelum REST populer, dunia enterprise lebih dulu mengadopsi SOAP. SOAP adalah singkatan dari Simple Object Access Protocol, yaitu sebuah protokol komunikasi berbasis XML yang digunakan untuk bertukar data antar sistem melalui jaringan, terutama dalam konteks Web Services (layanan web).

Struktur Utama SOAP:

● Envelope: Kerangka pembungkus yang memuat header dan body pesan.

○ Header: berisi informasi tambahan yang berkaitan dengan komunikasi SOAP, misal token autentikasi, detail enkripsi, dll

○ Body: bagian inti dari SOAP yang berisi data utama yang dikirim ke sistem tujuan

● Fault: Mekanisme error handling bawaan, memberikan detail kesalahan dalam format XML

Gambar 2.7.2 Struktur SOAP API

Cara Kerja SOAP API

Dalam praktiknya, komunikasi melalui SOAP diawali dengan permintaan (request) dari klien ke server. Permintaan ini dikirim dalam bentuk dokumen XML yang berisi informasi yang diperlukan untuk memanggil suatu metode atau layanan di server. Setelah menerima dan memproses permintaan tersebut, server akan memberikan respons dalam bentuk pesan SOAP, juga berupa XML, yang berisi hasil dari operasi yang

diminta.

Peran WSDL dalam SOAP API

Saat mengembangkan layanan berbasis SOAP, digunakan spesifikasi bernama WSDL (Web Services Description Language). WSDL adalah dokumen XML yang menjelaskan secara rinci bagaimana struktur layanan web tersebut: metode apa saja yang tersedia, bagaimana format permintaan dan responsnya, dan parameter apa saja yang dibutuhkan. WSDL memudahkan aplikasi lain untuk "mengerti" bagaimana cara berinteraksi dengan layanan SOAP secara otomatis, tanpa harus menebak struktur pesannya.

Berikut contoh struktur pesan SOAP yang berisi permintaan untuk mengambil data pelanggan tertentu:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Header>
    <authToken>123456</authToken>
</soap:Header>
<soap:Body>
    <getCustomerRequest>
      <customerId>987654</customerId>
    </getCustomerRequest>
</soap:Body>
</soap:Envelope>

Dalam contoh ini:

● <soap:Envelope> adalah pembungkus utama pesan SOAP.

● <soap:Header> berisi elemen authToken dengan nilai 123456, yang biasanya digunakan untuk keperluan otentikasi atau otorisasi.

● <soap:Body> berisi elemen getCustomerRequest, yang menunjukkan permintaan client untuk mengambil data pelanggan berdasarkan customerId bernilai 987654.

Struktur ini memberikan format standar yang memungkinkan client dan server saling memahami isi pesan dengan jelas dan terstruktur. Inilah kekuatan utama dari SOAP komunikasi yang formal, eksplisit, dan dapat dikontrol dengan ketat.

Berbeda dari REST yang ringan dan bebas format, SOAP sangat terstruktur dan formal. Setiap request dan response harus mengikuti aturan XML yang ketat. Ini bisa menjadi kelebihan maupun kekurangan tergantung konteksnya. Dalam dunia enterprise, SOAP tetap relevan karena:

● Mendukung WS-Security, termasuk digital signatures dan enkripsi tingkat tinggi

● Dapat digunakan untuk transaksi atomik (semua atau tidak sama sekali)

● Menjamin integritas dan konsistensi data di lingkungan sistem yang kompleks

● Mendukung pengiriman melalui protokol lain, seperti SMTP dan TCP, tidak hanya HTTP

Namun, dari sisi QA dan developer, SOAP bisa menjadi tantangan karena:

● Format XML lebih berat dan verbose (penjelasan atau informasi yang diberikan sangat detail dan panjang) dibanding JSON

● Dokumentasi dan validasi WSDL cukup kompleks

● Tidak fleksibel dalam integrasi cepat

Itulah mengapa banyak sistem modern beralih ke REST, kecuali jika memang membutuhkan fitur keamanan dan konsistensi tingkat tinggi yang ditawarkan oleh SOAP.

⬛ Perbandingan Praktis dari Kacamata QA

Sebagai QA Engineer, memahami perbedaan REST dan SOAP bukan hanya soal teknis, tapi juga berpengaruh terhadap:

● Cara menulis skenario pengujian

● Tools yang digunakan

● Tingkat kesulitan debugging

● Kecepatan automation

REST memungkinkan pengujian yang lebih cepat dan sederhana, cocok untuk agile dan startup. Sementara SOAP, meski kompleks, tetap dibutuhkan di lingkungan enterprise yang tidak bisa mentoleransi ketidakkonsistenan data.

Perbandingan antara REST dan SOAP:

Fitur / Aspek	REST	SOAP
Protokol	HTTP	HTTP, SMTP, TCP, dll
Format Data	JSON (umum), XML, HTML, dll	Hanya XML
*Berat (Overhead)*	Ringan	Berat (terutama XML & headers)
Keamanan	OAuth, HTTPS	WS-Security
Fleksibilitas	Tinggi	Terbatas pada standar XML
Dokumentasi	OpenAPI / Swagger	WSDL
Digunakan dalam	Web & mobile modern apps	Sistem enterprise & legacy

⬛ Studi Kasus 1: REST API dalam Aplikasi E-Commerce

Sebuah startup e-commerce lokal menggunakan REST API untuk menghubungkan frontend aplikasi mobile dengan backend-nya. Seluruh proses dari login pengguna, melihat katalog produk, menambahkan ke keranjang, hingga melakukan pembayaran dilakukan melalui REST endpoints.

Contoh Endpoint REST:

GET https://api.tokokita.com/products?category=shoes

Response JSON:

[
{
    "id": 1,
    "name": "Sepatu Lari ABC",
    "price": 450000,
    "stock": 23
},
{
    "id": 2,
    "name": "Sneakers XYZ",
    "price": 525000,
    "stock": 10
}
]

Kelebihan REST dalam studi kasus ini:

● Menggunakan JSON, mudah dibaca dan ringan dikirim via jaringan seluler.

● Skalabilitas tinggi: setiap tim frontend bisa mengakses resource sesuai kebutuhan.

● Fleksibel: bisa diakses via browser, Postman, curl, atau integrasi mobile app.

● Cocok untuk pengembangan cepat dan iteratif (agile).

Peran QA:

● QA dapat menggunakan Postman untuk mengetes endpoint login, keranjang, checkout.

● Melakukan status code validation (200 OK, 400 Bad Request, dll).

● Cek response JSON dengan skenario valid dan invalid.

⬛ Studi Kasus 2: SOAP API dalam Sistem Perbankan

Sebuah bank nasional menggunakan SOAP untuk pertukaran data internal antara core banking system dan sistem pihak ketiga seperti BI-FAST atau lembaga keuangan lain. Semua transaksi harus aman, tervalidasi, dan tercatat secara formal.

Contoh SOAP Request:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Header>
    <authToken>abc123</authToken>
</soap:Header>
<soap:Body>
    <getAccountBalanceRequest>
      <accountNumber>987654321</accountNumber>
    </getAccountBalanceRequest>
</soap:Body>
</soap:Envelope>

Kelebihan SOAP dalam studi kasus ini:

● Dukungan keamanan tingkat tinggi dengan WS-Security (enkripsi, digital signature).

● Kontrak layanan tetap dengan WSDL → lebih stabil, tidak mudah berubah.

● Mendukung transaksi kompleks dan atomic operation.

● Memungkinkan retry otomatis jika ada gangguan jaringan.

Peran QA:

● QA menggunakan SoapUI untuk mengirim dan memvalidasi request-response SOAP.

● Memastikan bahwa pesan XML sesuai skema dan tidak rusak (validasi WSDL).

Melakukan test dengan skenario error, seperti token salah, nomor akun tidak ditemukan.

Last modified: Thursday, 4 September 2025, 9:29 AM

2.7 Konsep Dasar API

2.7.1 Arsitektur API: Perbandingan REST dan SOAP

Namun, tidak semua API dibuat dengan cara yang sama. Selama dua dekade terakhir, dua pendekatan utama telah mendominasi cara API dirancang dan digunakan: REST (Representational State Transfer) dan SOAP (Simple Object Access Protocol).

⬛ REST: Modern, Ringan, dan Fleksibel

Cara Kerja REST API

Agar komunikasi antara klien dan server ini berjalan dengan benar, developer API akan menyediakan dokumentasi API, yaitu petunjuk teknis yang menjelaskan:

● Alamat (endpoint) apa yang bisa diakses,

● Metode HTTP apa yang digunakan (GET, POST, dll),

● Data apa yang harus dikirim,

● Format response yang akan diterima.

Alur Umum Kerja REST API

Berikut ini adalah tahapan standar dalam proses request–response REST API:

1. Klien mengirim permintaan (request)Klien merujuk ke dokumentasi API untuk mengetahui bagaimana cara menyusun request yang benar, misalnya, ke endpoint mana, metode HTTP apa yang digunakan (GET, POST, PUT, DELETE), serta apakah perlu menyertakan data atau parameter.

2. Server melakukan autentikasiServer akan memeriksa apakah klien yang mengirim permintaan memiliki hak akses yang sah. Biasanya, ini dilakukan melalui token otentikasi (seperti JWT atau Bearer Token).

3. Server memproses permintaanSetelah lolos autentikasi, server akan memproses request. Ini bisa mencakup pencarian data di database, pemrosesan logika bisnis, atau validasi data.

4. Server mengirim responseServer akan mengembalikan response kepada klien, yang biasanya berisi:

○ Status dari permintaan (berhasil atau gagal),

○ Data yang diminta (jika ada),

○ Atau pesan kesalahan jika terjadi error.

Komponen REST API

○ https://api.example.com/users/123/profile → Mengambil data profil pengguna dengan ID 123

Struktur URL

Path dan Query String keduanya merupakan jenis parameter pada URL.

● Path parameter: jalur menuju halaman atau file tertentu, biasanya untuk identifikasi resource. Contoh: GET /users/101/orders/20 → Mengakses pesanan ke-20 dari user dengan ID 101.

● HTTP Methods: REST memanfaatkan metode HTTP standar:

○ GET GET dipakai untuk mengambil atau melihat data dari server. Misalnya kamu mau lihat daftar transaksi, kamu tinggal kirim permintaan GET ke server.

Contoh:GET https://api.example.com/users/123

● HTTP Methods: GET→ membaca/mengambil data dari server.

● Path: /users/123 → endpoint untuk mengambil data pengguna dengan ID 123.

● Body: tidak ada (GET biasanya tidak mengirim body).

○ POST POST dipakai untuk mengirim data baru ke server, misalnya membuat pesanan baru atau entri baru.

Contoh:POST https://api.example.com/orders

● HTTP Methods: POST → mengirim data baru ke server.

● Path: /orders → endpoint untuk membuat pesanan baru.

● Body: berisi detail pesanan (misalnya produk, jumlah, harga), yang akan menambahkan pesanan baru ke sistem setiap kali permintaan dikirim.{

"produk": "Laptop",

"jumlah": 1

}

○ PUT PUT digunakan untuk memperbarui (mengganti) data yang sudah ada pada server. Berbeda dari POST, permintaan PUT bersifat idempotent, artinya jika dikirim berkali-kali dengan isi yang sama, hasilnya akan tetap sama, data akan diperbarui ke kondisi tertentu.

Contoh:PUT https://api.example.com/products/1001

● HTTP Methods: PUT→ memperbarui data secara keseluruhan.

● Path: /products/1001 → endpoint untuk memperbarui informasi produk dengan ID 1001.

● Body: berisi data lengkap yang diperbarui (misalnya produk, stok).{

"produk": "Laptop",

"stok": 5

}

○ DELETE DELETE digunakan untuk menghapus sumber daya dari server. Aksi ini akan mengubah kondisi server karena data yang dihapus tidak lagi tersedia. Namun, jika pengguna tidak memiliki izin akses yang sah (autentikasi/autorisasi), maka permintaan penghapusan akan ditolak.

Contoh:DELETE https://api.example.com/users/789

● HTTP Methods: DELETE→ menghapus data.

● Path: /users/789 → endpoint untuk menghapus data pengguna dengan ID 789

● Body: biasanya tidak ada (data dihapus berdasarkan path).

● HTTP Headers

● Request Body

● Status Code: Setiap request diikuti response dari server lengkap dengan status code.

⬛ Metode Autentikasi pada REST API

Sebelum server mengirimkan data melalui REST API, autentikasi harus dilakukan terlebih dahulu untuk memastikan bahwa permintaan (request) datang dari pengguna atau sistem yang memiliki hak akses yang sah.

Sama seperti saat kita menunjukkan KTP atau SIM untuk membuktikan identitas kita dalam kehidupan nyata, dalam REST API pun klien (client) harus membuktikan identitasnya kepada server agar dapat dipercaya dan mendapatkan akses ke resource yang diminta.

Mengapa Autentikasi Penting?

● Mencegah akses tidak sah ke data sensitif (seperti data transaksi atau informasi pelanggan),

● Memberi kontrol siapa yang boleh mengakses apa,

● Menjaga integritas dan keamanan sistem backend.

Jenis-Jenis Metode Autentikasi pada REST API

1. HTTP Authentication

Metode autentikasi ini sudah menjadi bagian dari standar protokol HTTP, dan terdiri dari dua skema populer:

a. Basic Authentication

● Klien mengirim username dan password melalui header dalam request.

● Informasi ini di-encode menggunakan Base64, yaitu metode pengkodean yang mengubah teks menjadi kombinasi 64 karakter agar aman ditransmisikan.

● Contoh penggunaan: cocok untuk sistem internal atau API testing di lingkungan terbatas, tapi tidak aman jika tanpa protokol HTTPS.

b. Bearer Token (Token-Based Authentication)

● Server memberikan sebuah token saat pengguna berhasil login.

● Token tersebut disimpan klien, dan digunakan dalam setiap request berikutnya melalui Authorization: Bearer <token>.

● Token biasanya berupa string acak yang sudah dienkripsi.

● Lebih aman dibanding basic auth karena password tidak dikirim setiap saat.

2. API Key

● Server menghasilkan API key unik untuk setiap klien saat pertama kali mendaftar.

● API key digunakan dalam setiap request sebagai tanda pengenal.

● Biasanya dikirim lewat header (x-api-key) atau sebagai parameter query.

● Kelemahan: rentan terhadap pencurian jika tidak dienkripsi atau dikirim lewat HTTP biasa.

3. OAuth (Open Authorization)

● Merupakan metode autentikasi paling aman dan fleksibel.

1. **Klien mengirim permintaan (request)**
Klien merujuk ke dokumentasi API untuk mengetahui bagaimana cara menyusun request yang benar, misalnya, ke endpoint mana, metode HTTP apa yang digunakan (GET, POST, PUT, DELETE), serta apakah perlu menyertakan data atau parameter.

2. Server melakukan autentikasi
Server akan memeriksa apakah klien yang mengirim permintaan memiliki hak akses yang sah. Biasanya, ini dilakukan melalui token otentikasi (seperti JWT atau Bearer Token).

3. Server memproses permintaan
Setelah lolos autentikasi, server akan memproses request. Ini bisa mencakup pencarian data di database, pemrosesan logika bisnis, atau validasi data.

4. Server mengirim response
Server akan mengembalikan response kepada klien, yang biasanya berisi:

○ GET
GET dipakai untuk mengambil atau melihat data dari server. Misalnya kamu mau lihat daftar transaksi, kamu tinggal kirim permintaan GET ke server.

Contoh:
GET https://api.example.com/users/123

○ POST
POST dipakai untuk mengirim data baru ke server, misalnya membuat pesanan baru atau entri baru.

Contoh:
POST https://api.example.com/orders

● Body: berisi detail pesanan (misalnya produk, jumlah, harga), yang akan menambahkan pesanan baru ke sistem setiap kali permintaan dikirim.
{

○ PUT
PUT digunakan untuk memperbarui (mengganti) data yang sudah ada pada server. Berbeda dari POST, permintaan PUT bersifat idempotent, artinya jika dikirim berkali-kali dengan isi yang sama, hasilnya akan tetap sama, data akan diperbarui ke kondisi tertentu.

Contoh:
PUT https://api.example.com/products/1001

● Body: berisi data lengkap yang diperbarui (misalnya produk, stok).
{

○ DELETE
DELETE digunakan untuk menghapus sumber daya dari server. Aksi ini akan mengubah kondisi server karena data yang dihapus tidak lagi tersedia. Namun, jika pengguna tidak memiliki izin akses yang sah (autentikasi/autorisasi), maka permintaan penghapusan akan ditolak.

Contoh:
DELETE https://api.example.com/users/789

b. Bearer Token **(Token-Based Authentication)**

**3. OAuth (Open Authorization)**