REST API adalah gaya arsitektur yang umum dipakai untuk membangun layanan web yang berkomunikasi lewat HTTP dengan resource dan representasi data seperti JSON.
Panduan ini menjelaskan konsep dasar, prinsip REST, contoh endpoint nyata, praktik keamanan, serta langkah implementasi sederhana agar pembaca bisa memahami dan mulai membangun REST API secara praktis dan terstruktur.
Apa Perbedaan API dan REST API?
Pertanyaan yang sering muncul: apa beda API dan REST API? Singkatnya, API adalah istilah umum untuk antarmuka yang memungkinkan dua sistem berkomunikasi; sedangkan REST API adalah jenis API yang mengikuti prinsip REST—stateless, berbasis resource, dan menggunakan HTTP methods, seperti GET/POST/PUT/DELETE.
💻 Mulai Belajar Pemrograman
Belajar pemrograman di Dicoding Academy dan mulai perjalanan Anda sebagai developer profesional.
Daftar SekarangREST menekankan format representasi (biasanya JSON) dan URL sebagai alamat resource. Sekarang, mari kita masuk ke detail pertama: memahami perbedaan API dan arsitektur REST.
Memahami Perbedaan API dan Arsitektur REST
API adalah cara satu komponen perangkat lunak berkomunikasi dengan komponen lain melalui sebuah interface. Bentuknya tidak selalu HTTP; bisa berupa library API dalam satu proses, RPC seperti gRPC, atau GraphQL API yang memakai satu endpoint fleksibel. Intinya, API mendefinisikan kontrak: hal yang boleh diminta dan hal yang akan dikembalikan.
REST adalah gaya arsitektur untuk API berbasis HTTP yang berfokus pada resource. Setiap resource punya identifier (biasanya URL) dan bisa punya banyak representation, seperti JSON atau XML.
REST menekankan beberapa prinsip: stateless di sisi server, uniform interface dengan pola HTTP yang konsisten, respons yang cacheable, dan dukungan layered system, seperti gateway atau load balancer.
Dibanding istilah API yang sangat umum, REST berada pada level arsitektur yang lebih spesifik untuk layanan HTTP. Kamu biasanya memilih REST saat butuh integrasi luas, dukungan tooling matang, dan pola sederhana berbasis resource.
Alternatif seperti gRPC atau GraphQL menarik untuk kebutuhan real-time, strong typing, atau query fleksibel, tetapi membawa kompleksitas dan pola desain yang berbeda. Dalam bagian berikutnya, kita akan masuk pada detail batasan dan aturan REST yang membuat desain tersebut konsisten serta mudah diuji.
Prinsip Dasar Batasan dan Aturan REST API
Dalam REST, beberapa constraint utama sangat memengaruhi desain. Layanan harus stateless: server tidak menyimpan konteks sesi sehingga setiap permintaan membawa semua data yang dibutuhkan.
Resource diidentifikasi lewat URI yang stabil, misalnya /api/users/123, bukan lewat action seperti /getUser. Representasi data umumnya memakai JSON sehingga struktur respons perlu konsisten dan mudah di-parse klien.
Pemilihan endpoint mengikuti bentuk jamak dan berbasis noun, misalnya /products dan /products/{id}. HTTP method digunakan sesuai makna: GET untuk baca, POST untuk membuat, PUT untuk mengganti, PATCH untuk ubah sebagian, dan DELETE untuk hapus.
Kode status juga harus tepat, misalnya 200, 201, 400, 404, dan 500, agar klien bisa menangani respons dengan benar.
Dokumentasi yang rapi dan konsisten sangat penting, misalnya memakai OpenAPI atau Swagger. Versioning bisa melalui path seperti /v1/orders agar perubahan besar tidak merusak klien lama.
Konsep HATEOAS dapat diterapkan ringan dengan menambahkan links pada respons untuk mengarahkan ke resource terkait sehingga navigasi antarlayanan lebih terstruktur.
Contoh Penerapan Endpoint dan HTTP Methods pada Aplikasi
Bayangkan aplikasi sederhana manajemen tugas. Kamu punya resource utama /tasks dengan operasi CRUD: GET /tasks (list), POST /tasks (buat), GET /tasks/{id} (detail), PUT /tasks/{id} (update penuh), PATCH /tasks/{id} (update sebagian), dan DELETE /tasks/{id} (hapus). Struktur URI konsisten memudahkan klien menebak perilaku endpoint.
Contoh request untuk membuat tugas baru sebagai berikut.
|
1 2 3 4 5 6 7 8 9 |
POST /tasks Content-Type: application/json { "title": "Belajar REST API", "description": "Baca dokumentasi dan coba contoh", "due_date": "2026-06-01", "status": "pending" } |
Contoh response berhasil sebagai berikut.
|
1 2 3 4 5 6 7 8 9 10 11 |
HTTP/1.1 201 Created Location: /tasks/123 { "id": 123, "title": "Belajar REST API", "description": "Baca dokumentasi dan coba contoh", "due_date": "2026-06-01", "status": "pending", "created_at": "2026-05-28T10:00:00Z" } |
Flow penggunaan biasanya diawali autentikasi. Misalnya login dengan POST /auth/login dan menerima access token.
|
1 2 3 4 5 6 7 |
POST /auth/login Content-Type: application/json { "email": "user@example.com", "password": "rahasia123" } |
Lalu, klien mengirim Authorization header pada setiap permintaan.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
GET /tasks?page=1&limit=10&status=pending Authorization: Bearer <access_token> Accept: application/json Contoh response dengan paginasi dan filtering sebagai berikut. HTTP/1.1 200 OK { "data": [ { "id": 101, "title": "Tugas 1", "status": "pending" }, { "id": 102, "title": "Tugas 2", "status": "pending" } ], "pagination": { "page": 1, "limit": 10, "total_items": 25, "total_pages": 3 }, "filters": { "status": "pending" } } |
Error handling yang konsisten membantu debugging. Misalnya, ketika task tidak ditemukan.
|
1 2 3 4 5 6 7 8 9 10 |
GET /tasks/9999 HTTP/1.1 404 Not Found Content-Type: application/json { "error": "NotFoundError", "message": "Task dengan id 9999 tidak ditemukan", "code": 404 } |
Untuk testing cepat, kamu bisa pakai curl di terminal.
curl -X GET “https://api.example.com/tasks?page=1&limit=5” \
-H “Authorization: Bearer <access_token>” \
-H “Accept: application/json”
Atau gunakan Postman untuk menyimpan koleksi endpoint, mengatur environment, dan mengulang tes dengan mudah. Ceklis singkat: pastikan setiap method mengembalikan status code HTTP yang tepat, body JSON valid, header seperti Content-Type dan Authorization benar, serta error selalu memiliki struktur respons yang konsisten.
Praktik Terbaik Keamanan Versi dan Testing API
Setiap endpoint yang sudah kamu buat perlu dilindungi dengan lapisan keamanan yang konsisten. Gunakan autentikasi berbasis token, seperti OAuth 2.0 atau JWT, lalu batasi hak akses dengan otorisasi berbasis role atau scope.
Terapkan validasi input ketat di sisi server, rate limiting untuk mencegah abuse, dan pastikan semua trafik lewat HTTPS agar data terenkripsi selama transport.
Versi API sebaiknya dikelola eksplisit, misalnya pada URL seperti /api/v1/users. Jaga backward compatibility dengan tidak menghapus atau mengubah perilaku field yang sudah ada, tetapi tambahkan field baru secara opsional.
Saat perlu perubahan besar, buat versi baru, dokumentasikan breaking changes, tetapkan deprecation policy yang jelas, dan komunikasikan batas waktu migrasi ke konsumen API.
Untuk kualitas, susun unit test dan integration test bagi setiap endpoint, lalu gunakan contract testing agar kesepakatan format respons tidak mudah rusak. Mock server membantu tim klien mengembangkan lebih cepat tanpa menunggu layanan nyata selalu aktif.
Dalam produksi, aktifkan monitoring dan structured logging untuk memantau error, latensi, serta pola trafik sehingga insiden bisa terdeteksi dan ditangani lebih cepat.
Penutup
Artikel ini memberi Anda kerangka untuk memahami REST API: mulai dari perbedaan dengan API umum, prinsip dasar, contoh endpoint, sampai praktik keamanan dan testing. Tujuannya agar Anda dapat merancang dan menguji layanan berbasis HTTP secara lebih percaya diri. Gunakan contoh dan ceklis dalam artikel ini untuk mulai implementasi nyata.
