REST #

REST (Representational State Transfer) adalah salah satu pendekatan arsitektur paling populer dalam membangun API dan sistem terdistribusi modern. Hampir semua backend service saat ini—mulai dari startup kecil hingga perusahaan teknologi besar—menggunakan REST atau setidaknya terinspirasi olehnya.

Namun, REST sering disalahpahami hanya sebagai “API berbasis HTTP + JSON”. Padahal, REST adalah sebuah architectural style dengan filosofi, prinsip, dan constraint yang jelas.

Artikel ini akan membahas REST secara menyeluruh: sejarahnya, nilai pentingnya, kelebihan dan kekurangannya dibanding metode lain, serta best practice penerapannya di dunia nyata.

Sejarah REST #

REST pertama kali diperkenalkan oleh Roy Fielding pada tahun 2000 dalam disertasinya yang berjudul Architectural Styles and the Design of Network-based Software Architectures.

Roy Fielding adalah salah satu kontributor utama spesifikasi HTTP (HTTP/1.1). Dari pengalamannya melihat bagaimana web berkembang, ia merumuskan REST sebagai gaya arsitektur yang menjelaskan mengapa web bisa berskala besar, tahan perubahan, dan terdistribusi secara global.

Penting untuk dicatat:

• REST bukan standar seperti SOAP
• REST bukan protokol
• REST adalah sekumpulan constraint arsitektur

HTTP hanyalah salah satu implementasi paling natural dari REST, karena HTTP secara desain memang selaras dengan prinsip REST.

Apa Itu REST? #

REST adalah architectural style untuk sistem terdistribusi yang berfokus pada resource, representasi resource, dan interaksi stateless.

Konsep kunci REST:

• Resource: Segala sesuatu dianggap sebagai resource (user, order, product, dll)
• Representation: Resource direpresentasikan dalam bentuk tertentu (JSON, XML, dll)
• Uniform Interface: Cara interaksi yang konsisten dan seragam

Contoh sederhana:

• /users/123 → resource user dengan ID 123
• Representasinya bisa berupa JSON

Constraint Utama REST #

REST memiliki 6 constraint utama. Sebuah sistem baru bisa disebut “RESTful” jika memenuhi constraint ini.

Client–Server #

• Client dan server dipisahkan secara jelas
• Client fokus pada UI / experience
• Server fokus pada data dan logic

Dampak:

• Skalabilitas meningkat
• Independensi development antara client dan server

Stateless #

• Setiap request harus membawa semua informasi yang dibutuhkan
• Server tidak menyimpan state client

Contoh:

• Auth menggunakan token (JWT, API key)
• Bukan session server-side

Dampak:

• Mudah diskalakan
• Lebih fault-tolerant

Cacheable #

• Response harus mendefinisikan apakah bisa di-cache atau tidak
• Menggunakan mekanisme cache HTTP (Cache-Control, ETag, dll)

Dampak:

• Performa meningkat
• Beban server berkurang

Uniform Interface #

Uniform Interface terdiri dari beberapa prinsip:

• Identifikasi resource melalui URI
• Manipulasi resource melalui representasi
• Pesan bersifat self-descriptive
• HATEOAS (opsional, sering diabaikan di praktik)

Tujuan utama:

• Konsistensi
• Decoupling client dan server

Layered System #

• Client tidak perlu tahu apakah ia terhubung langsung ke server atau melalui layer lain (gateway, proxy, load balancer)

Dampak:

• Mendukung arsitektur microservices
• Mendukung API gateway

Code on Demand (Opsional) #

• Server dapat mengirim executable code ke client (misalnya JavaScript)
• Jarang digunakan pada API modern

Nilai Penting REST #

Skalabilitas Tinggi #

REST secara natural mendukung sistem berskala besar karena:

• Stateless
• Cacheable
• Client–server separation

Inilah alasan utama REST cocok untuk:

• Microservices
• Public API
• Cloud-native system

Kesederhanaan dan Konsistensi #

REST mendorong:

• Resource-based design
• Uniform interface

Hasilnya:

• API mudah dipahami
• Onboarding developer lebih cepat

Fleksibel terhadap Perubahan #

Dengan REST:

• Client tidak tergantung implementasi internal server
• Representasi bisa berkembang tanpa merusak kontrak

Ini sangat penting untuk:

• Produk jangka panjang
• Sistem dengan banyak consumer

Kelebihan REST #

1. Sederhana dan familiar

   • Berbasis HTTP
   • Mudah dipelajari

2. Tooling sangat matang

   • Browser, curl, Postman
   • HTTP cache, proxy, CDN

3. Bahasa & platform agnostic

   • Bisa digunakan oleh hampir semua stack

4. Cocok untuk public API

   • Mudah didokumentasikan
   • Mudah dikonsumsi

Kekurangan REST #

Over-fetching dan Under-fetching #

Client sering:

• Mendapat data terlalu banyak
• Atau harus melakukan banyak request

Ini umum terjadi pada REST API yang tidak dirancang dengan baik.

Tidak Ideal untuk Real-time #

REST berbasis request–response:

• Kurang cocok untuk real-time
• Biasanya perlu dikombinasikan dengan WebSocket atau SSE

Verbose untuk Operasi Kompleks #

Untuk workflow kompleks:

• Banyak endpoint
• Banyak round-trip

Kadang lebih cocok menggunakan pendekatan lain.

REST vs Metode Lain #

REST vs SOAP #

REST vs GraphQL #

REST vs gRPC #

Best Practice REST API #

Gunakan Resource-oriented Design #

❌ /getUserById

✅ /users/{id}

Gunakan HTTP method:

• GET
• POST
• PUT / PATCH
• DELETE

Gunakan HTTP Status Code dengan Benar #

• 200 OK
• 201 Created
• 400 Bad Request
• 401 Unauthorized
• 403 Forbidden
• 404 Not Found
• 500 Internal Server Error

Ini bagian dari uniform interface.

Konsisten dalam Naming dan Struktur #

• Gunakan plural noun (/users, /orders)
• Gunakan lowercase
• Hindari verb di URL

Versioning API dengan Jelas #

Contoh:

• /api/v1/users

Atau melalui header.

Gunakan Pagination, Filtering, Sorting #

Contoh:

• /users?page=1&limit=20
• /orders?status=paid&sort=created_at

Dokumentasi adalah Wajib #

• Gunakan OpenAPI / Swagger
• Dokumentasi adalah kontrak, bukan pelengkap

Jangan Memaksakan REST untuk Semua Masalah #

REST bukan solusi untuk semua hal:

• Real-time → WebSocket
• Internal high-performance → gRPC
• Data fetching kompleks → GraphQL

Arsitek yang baik tahu kapan menggunakan REST dan kapan tidak.

Penutup #

REST bertahan lebih dari dua dekade bukan karena sempurna, tetapi karena prinsipnya kuat dan relevan. Ia mendorong kesederhanaan, konsistensi, dan skalabilitas—tiga hal krusial dalam software engineering.

Memahami REST sebagai architectural style, bukan sekadar “API JSON”, akan membantu kita membangun sistem yang lebih sehat, tahan perubahan, dan mudah dikembangkan dalam jangka panjang.