soal 1

API: Jembatan Komunikasi Antar Aplikasi

Bayangkan Anda sedang berada di restoran. Anda tidak langsung pergi ke dapur untuk memasak makanan sendiri, kan? Anda cukup memesan kepada pelayan, dan pelayanlah yang akan menyampaikan pesanan Anda ke dapur dan membawakan makanan yang sudah jadi.

Nah, API (Application Programming Interface) itu mirip seperti pelayan tadi. Dalam dunia digital, API adalah “pelayan” yang memungkinkan dua aplikasi atau sistem yang berbeda untuk “berbicara” satu sama lain dan bertukar informasi atau fungsionalitas.

Secara sederhana, API adalah seperangkat aturan dan protokol yang memungkinkan perangkat lunak yang berbeda untuk berinteraksi. Ini mendefinisikan metode dan format data yang harus digunakan aplikasi untuk meminta dan bertukar informasi. Tanpa API, aplikasi akan sulit untuk bekerja sama, seperti halnya restoran tanpa pelayan akan kacau balau.

Contoh API dalam Kehidupan Sehari-hari

Berikut adalah contoh API yang sering kita gunakan tanpa menyadarinya:

1. API Google Maps

Hampir setiap aplikasi yang membutuhkan informasi lokasi atau navigasi, seperti aplikasi taksi online, aplikasi pengiriman makanan, atau bahkan aplikasi perbankan untuk mencari lokasi ATM terdekat, menggunakan API Google Maps.

Fungsi sederhananya: API ini memungkinkan aplikasi lain untuk menampilkan peta, mencari alamat, menghitung rute perjalanan, atau bahkan menampilkan informasi lalu lintas secara real-time. Jadi, daripada setiap aplikasi harus membuat sistem petanya sendiri dari awal, mereka cukup “meminta” informasi dari Google Maps melalui API-nya.

soal 2

Stateless vs. Stateful API: Apa Bedanya?

Gini lho, API itu kan jembatan komunikasi antar aplikasi. Nah, ada dua jenis jembatan yang cara kerjanya beda:

1. Stateless API (Nggak Punya Ingatan)

Bayangin kita lagi nelpon customer service. Kalau pakai Stateless API, setiap kali kita nelpon, kita harus ngulang semua informasi dari awal: “Halo, saya Budi, nomor ID saya sekian, masalah saya ini.” Customer service-nya nggak inget obrolan kita sebelumnya. Setiap permintaan itu mandiri, server nggak nyimpen “kondisi” atau info dari interaksi kita sebelumnya.

Poin utamanya: Server nggak perlu repot-repot nyimpen data sesi kita. Setiap permintaan yang masuk itu lengkap, jadi server tinggal proses aja.

2. Stateful API (Punya Ingatan)

Nah, kalau Stateful API ini beda. Ini kayak kita lagi chat sama customer service via WhatsApp. Customer service-nya inget apa yang udah kita obrolin sebelumnya dalam sesi chat itu. Jadi, kita bisa ngelanjutin obrolan tanpa harus ngulang dari awal. Server itu “mengingat” kondisi atau riwayat interaksi kita.

Poin utamanya: Server nyimpen data sesi kita, jadi permintaan selanjutnya bisa bergantung pada informasi yang udah ada sebelumnya.

Mana yang Lebih Cocok untuk Aplikasi Pemesanan Tiket Online?

Menurut kita, untuk aplikasi pemesanan tiket online, Stateless API itu jauh lebih cocok! Kenapa?

Gampang di-Skala (Kalau Rame Nggak Masalah): Aplikasi tiket online kan kadang mendadak rame banget, apalagi kalau ada konser atau promo besar. Nah, kalau pakai Stateless, server nggak perlu mikirin “memori” sesi tiap user. Jadi, kita bisa nambah atau kurangin jumlah server dengan gampang banget biar aplikasinya nggak downpas lagi rame.
Lebih Tahan Banting (Kalau Server Ngadat Nggak Masalah Besar): Misal nih, ada satu server yang lagi ngadat di tengah proses pemesanan tiket. Kalau pakai Stateless, permintaan kita bisa langsung dialihkan ke server lain dan tetap lanjut. Server baru itu nggak perlu “belajar” lagi dari awal karena setiap permintaan udah lengkap. Beda kalau Stateful, bisa-bisa sesi kita putus dan harus ngulang semua dari awal.
Pengembangan Lebih Simpel: Kita sebagai pengembang di sisi aplikasi (HP atau website) juga lebih gampang, karena nggak perlu pusing mikirin cara nyimpen “memori” sesi. Setiap permintaan itu berdiri sendiri.

Meskipun proses pemesanan tiket itu berurutan (cari tiket, pilih kursi, bayar), “kondisi” atau “state” proses ini disimpan di database backend kita, bukan di server API-nya. Jadi, API kita tetap bekerja secara stateless untuk setiap permintaan.

Gimana, sekarang udah lebih kebayang kan bedanya?

soal 3

1. `GET /products`

Ini kayak kamu lagi buka katalog belanja online. Ketika aplikasi kamu (misalnya, di HP atau browser) bilang ke server, “Hei, kasih liat dong semua produk yang ada!”, nah, GET /products inilah yang bekerja. Server kemudian akan mengirimkan daftar lengkap produk, lengkap dengan nama, harga, deskripsi, dan lain-lain, biasanya dalam format yang mudah dibaca komputer (JSON). Jadi, intinya, endpoint ini buat nampilin semua produk yang bisa dibeli.

2. `POST /orders`

Nah, kalau yang ini ceritanya kamu udah selesai pilih-pilih barang di keranjang belanja dan siap bayar. Ketika kamu klik tombol “Pesan Sekarang” atau “Bayar”, aplikasi kamu akan “ngirim” semua detail pesanan (barang apa aja, berapa harganya, alamat kirimnya ke mana) ke server lewat POST /orders. Ini seperti kamu ngasih surat pesanan ke toko. Server akan menerima pesananmu, mencatatnya di database, terus ngasih tahu kamu kalau pesananmu udah diterima. Jadi, endpoint ini buat bikin pesanan baru.

3. `GET /orders/{orderId}`

Setelah kamu bikin pesanan, kadang kamu pengen lihat statusnya, kan? Misalnya, “Pesanan nomor 123 saya udah sampai mana ya?”. Nah, di sinilah GET /orders/{orderId} berperan. Kamu tinggal kasih tahu nomor pesananmu (orderId), terus server akan mencari detail lengkap pesanan itu. Contohnya, statusnya udah dikirim belum, barang apa aja yang dipesan, dan lain-lain. Ini kayak kamu ngecek detail pesanan spesifik kamu.

4. `DELETE /products/{productId}`

Yang terakhir ini lebih ke urusan admin atau pemilik toko. Anggap saja ada produk yang sudah tidak dijual lagi atau stoknya habis total dan tidak akan restock. Pemilik toko bisa “menghilangkan” produk itu dari katalog. Caranya, aplikasi admin akan memanggil DELETE /products/{productId} dengan menyebutkan ID produk yang mau dihapus. Server akan langsung menghapus produk itu dari daftar. Jadi, ini buat menghapus produk dari daftar katalog.