Ada banyak cara agar dua aplikasi bisa saling bicara, dan hampir semuanya berjalan lewat API (Application Programming Interface) — perantara yang membuat satu program bisa meminta data ke program lain. Namun dari sekian banyak gaya membangun API, ada satu yang begitu mendominasi web modern sehingga sering dianggap standar tidak resmi: REST.
REST API adalah API yang dibangun mengikuti sekumpulan aturan bernama REST, sehingga permintaan dan jawabannya menjadi rapi, seragam, dan mudah ditebak. Saat aplikasi ponsel Anda menarik daftar produk, saat sebuah website menampilkan cuaca hari ini, atau saat aplikasi ojek mengambil titik lokasi Anda — besar kemungkinan yang bekerja di baliknya adalah REST API. Artikel ini akan menjelaskan apa itu REST, mengapa ia bukan sekadar "jenis teknologi", cara kerjanya, hingga kelemahan yang jarang dibahas tuntas.
Apa Itu REST API?
REST API adalah antarmuka yang memungkinkan dua sistem bertukar data melalui internet dengan mengikuti gaya arsitektur REST (Representational State Transfer). Kata kuncinya ada pada "gaya arsitektur": REST bukan sebuah aplikasi, bukan produk yang bisa Anda unduh, dan bukan pula protokol jaringan. REST adalah sekumpulan aturan dan prinsip tentang bagaimana sebuah API sebaiknya ditata.
Inilah miskonsepsi paling umum di kalangan pemula. Banyak yang mengira REST adalah semacam teknologi tersendiri yang setara dengan bahasa pemrograman. Padahal REST lebih tepat dibayangkan sebagai aturan main. Ia menumpang di atas protokol yang sudah ada, yaitu HTTP — protokol yang sama yang dipakai browser Anda untuk membuka halaman web dan yang menjadi dasar koneksi aman HTTPS. REST hanya mengatur bagaimana permintaan disusun dan bagaimana jawaban dikembalikan agar konsisten.
Istilah REST pertama kali diperkenalkan oleh Roy Fielding dalam disertasi doktoralnya pada tahun 2000. Fielding kebetulan juga salah satu orang di balik spesifikasi HTTP, sehingga tidak mengherankan bila REST dirancang untuk memanfaatkan HTTP semaksimal mungkin. Sebuah API yang mematuhi aturan-aturan REST inilah yang kita sebut REST API.
Kalau Anda belum familiar dengan konsep API secara umum, ada baiknya membaca dulu penjelasan dasar tentang API dan cara kerjanya, karena REST adalah salah satu gaya di dalam payung besar API.
REST, RESTful, dan API Biasa: Meluruskan Kerancuan
Tiga istilah ini sering tertukar, jadi mari kita luruskan satu per satu.
- API adalah payung besarnya: perantara umum agar dua program bisa saling bertukar data. API tidak mengharuskan aturan tertentu.
- REST adalah gaya atau aturan spesifik untuk membangun API. Ia menetapkan sejumlah prinsip yang harus dipenuhi.
- RESTful adalah kata sifat untuk menyebut API yang sudah mematuhi aturan REST. Jadi "API RESTful" berarti API yang taat pada gaya REST.
Karena itu, pertanyaan tentang perbedaan REST API dan RESTful API sebenarnya lebih soal tata bahasa daripada teknis. Keduanya menunjuk hal yang sama: API yang dibangun mengikuti REST. Anda bebas memakai istilah mana pun tanpa risiko salah arti.
Lalu apa bedanya dengan "API biasa"? Bayangkan sebuah API yang dibuat tanpa aturan baku. Satu fungsi dinamai ambilData, fungsi lain hapus_user_sekarang, dan yang ketiga UpdateProfilBaru. Semuanya bekerja, tetapi tidak ada pola yang konsisten. Developer yang baru bergabung harus menghafal setiap nama satu per satu. REST hadir untuk menertibkan kekacauan seperti itu: ia menyediakan pola yang seragam sehingga siapa pun yang paham REST bisa langsung menebak cara memakai API tersebut, bahkan tanpa membaca dokumentasi panjang.
Cara Kerja REST API
Cara kerja REST API berputar pada satu pola sederhana: permintaan dan jawaban (request–response). Aplikasi yang meminta data disebut klien (client), sedangkan pihak yang menyimpan data dan menjawab disebut server. Klien mengirim permintaan, server memprosesnya, lalu mengembalikan jawaban. Selesai. Setelah itu koneksi dianggap tuntas.
Supaya lebih membumi, bayangkan sebuah kompleks perumahan. Setiap data yang bisa diakses — misalnya data seorang pengguna, sebuah produk, atau satu pesanan — kita sebut resource (sumber daya), dan setiap resource punya alamat tetap seperti alamat rumah. Alamat inilah yang dalam dunia REST disebut endpoint. Untuk mengurus rumah tersebut, Anda mengirim kurir dengan instruksi tertentu: antarkan barang, ambil barang, ganti isi, atau kosongkan. Server berperan sebagai penghuni yang menerima instruksi dan menanggapinya.
Ada satu sifat penting yang wajib dipahami: REST bersifat stateless (tanpa menyimpan status). Artinya, server tidak mengingat permintaan Anda sebelumnya. Setiap permintaan harus membawa semua informasi yang dibutuhkan untuk diproses, seolah-olah itu perkenalan pertama. Ibarat kurir yang tidak pernah ingat pernah mengantar ke rumah yang sama kemarin — setiap kali datang, ia butuh alamat dan instruksi lengkap lagi. Sifat ini membuat REST API sederhana dan mudah diperbesar skalanya, karena server tidak perlu repot menyimpan riwayat setiap klien.
Anatomi Satu Permintaan REST API
Agar tidak berhenti di teori, mari kita bedah wujud nyata satu permintaan REST API. Setiap permintaan umumnya terdiri dari beberapa bagian:
- Endpoint (alamat resource): alamat yang menunjuk ke data tertentu, misalnya
/users/42untuk pengguna bernomor 42. Endpoint ini bagian dari sebuah URL lengkap. - Metode HTTP: instruksi tentang apa yang ingin dilakukan terhadap resource. Empat yang paling sering dipakai adalah GET (mengambil data), POST (membuat data baru), PUT (memperbarui data), dan DELETE (menghapus data).
- Header: informasi tambahan, seperti
Authorizationuntuk membuktikan identitas atauContent-Typeuntuk menyebut format data yang dikirim. - Body: isi data yang dikirim, biasanya saat membuat atau memperbarui sesuatu.
Keempat metode HTTP di atas kebetulan memetakan rapi ke empat operasi dasar pengelolaan data yang dikenal sebagai CRUD — Create, Read, Update, Delete. Pemetaan inilah yang membuat REST terasa alami: Anda tidak perlu menghafal nama fungsi, cukup memilih metode yang sesuai dengan niat Anda.
| Metode HTTP | Operasi CRUD | Contoh permintaan | Artinya |
|---|---|---|---|
| GET | Read | GET /users/42 | Ambil data pengguna bernomor 42 |
| POST | Create | POST /users | Buat pengguna baru |
| PUT | Update | PUT /users/42 | Perbarui data pengguna 42 |
| DELETE | Delete | DELETE /users/42 | Hapus pengguna 42 |
Setelah menerima permintaan, server membalas dengan dua hal: data dan kode status. Datanya umumnya dikirim dalam format JSON (JavaScript Object Notation) karena ringkas dan mudah dibaca oleh mesin maupun manusia. Kode status adalah angka tiga digit yang memberitahu hasil permintaan: 200 berarti berhasil, 201 berarti data baru berhasil dibuat, 400 berarti permintaan salah format, 401 berarti Anda belum berwenang, 404 berarti resource tidak ditemukan, dan 500 berarti ada kesalahan di sisi server.
Alur satu permintaan sederhana bisa digambarkan seperti berikut:
Diagram alur kerja REST API antara klien, server, dan basis data dengan permintaan serta respons JSON.
Satu hal kecil tetapi penting soal penamaan endpoint: dalam REST, alamat resource sebaiknya berupa kata benda, bukan kata kerja. Jadi Anda menulis /users/42 dan membiarkan metode GET yang menyatakan niat "ambil". Menulis /getUser/42 dianggap kurang tepat karena mencampur aksi ke dalam alamat, padahal aksi sudah menjadi tugas metode HTTP. Aturan sederhana ini yang sering terlewat oleh pemula.
Enam Aturan yang Membuat Sebuah API Disebut REST
Sebuah API baru pantas disebut RESTful bila memenuhi sejumlah aturan yang dirumuskan Roy Fielding. Ada enam aturan, dan lima di antaranya wajib.
- Client-server (pemisahan peran): klien yang mengurus tampilan dan server yang mengurus data harus terpisah. Keduanya bisa dikembangkan sendiri-sendiri selama tetap sepakat pada format pertukarannya.
- Stateless (tanpa menyimpan status): seperti dijelaskan sebelumnya, server tidak mengingat permintaan lampau. Setiap permintaan berdiri sendiri dan harus lengkap.
- Cacheable (bisa disimpan sementara): jawaban dari server boleh ditandai agar bisa disimpan sementara oleh klien. Dengan begitu, permintaan yang sama tidak perlu selalu menempuh perjalanan penuh ke server.
- Uniform interface (antarmuka seragam): inilah jantung REST. Cara mengakses resource harus konsisten dan mengikuti pola yang sama di seluruh API, sehingga mudah dipelajari sekali dan dipakai di mana saja.
- Layered system (sistem berlapis): antara klien dan server boleh ada perantara seperti penyeimbang beban atau gateway, tanpa klien perlu tahu keberadaannya.
- Code on demand (kode sesuai permintaan): server boleh mengirim potongan kode untuk dijalankan klien. Aturan ini bersifat opsional dan paling jarang dipakai.
Kelima aturan wajib itulah yang membuat REST API bisa diperbesar dengan tenang, mudah dirawat, dan konsisten dari satu bagian ke bagian lain.
Infografis enam prinsip REST API: client-server, stateless, cacheable, uniform interface, layered system, code on demand.
Contoh REST API dalam Praktik
Konsep di atas akan lebih terasa nyata lewat contoh yang Anda temui sehari-hari:
- Login dengan akun Google: saat sebuah aplikasi menawarkan "Masuk dengan Google", di baliknya ia memanggil REST API milik Google untuk memverifikasi identitas Anda.
- Cek ongkir di toko online: ketika biaya pengiriman muncul otomatis di halaman pembayaran, aplikasi toko mengirim permintaan GET ke REST API perusahaan kurir dengan data kota asal dan tujuan.
- Cuaca dan peta: aplikasi cuaca menarik data dari REST API layanan meteorologi, sementara aplikasi transportasi mengambil titik lokasi lewat REST API peta.
- Dompet digital: saat saldo terpotong setelah pembayaran, sebuah permintaan POST dikirim ke REST API penyedia dompet untuk mencatat transaksi.
Di sisi developer, membangun REST API bisa dilakukan dengan hampir semua bahasa dan kerangka kerja modern. Framework seperti Laravel di PHP, Express di Node.js, atau Django di Python semuanya menyediakan cara ringkas untuk membuat endpoint REST. Setelah jadi, REST API perlu berjalan di sebuah server agar bisa diakses publik — banyak developer memilih VPS karena memberi kontrol penuh atas lingkungan tempat aplikasi dijalankan.
Kelemahan dan Hal yang Perlu Anda Pertimbangkan
REST populer bukan tanpa alasan, tetapi ia bukan jawaban untuk segala situasi. Ada beberapa sisi yang perlu Anda timbang.
Pertama, respons REST cenderung kaku. Sebuah endpoint biasanya mengembalikan bentuk data yang tetap. Akibatnya bisa muncul dua masalah: over-fetching, yaitu Anda menerima lebih banyak data daripada yang dibutuhkan, dan under-fetching, yaitu satu permintaan tidak cukup sehingga Anda harus memanggil beberapa endpoint sekaligus. Untuk aplikasi ponsel yang hemat data, hal ini bisa terasa boros.
Kedua, sifat stateless punya konsekuensi. Karena server tidak mengingat apa pun, setiap permintaan harus membawa ulang informasi seperti token identitas. Ini menambah sedikit beban pada setiap permintaan, meski imbalannya adalah kesederhanaan dan skala yang lebih mudah.
Ketiga, REST tidak memaksakan satu standar ketat. REST hanya seperangkat prinsip, bukan aturan baku yang diperiksa mesin. Dua tim bisa sama-sama mengaku membangun REST API tetapi menghasilkan penataan yang berbeda. Konsistensi tetap bergantung pada disiplin developer-nya.
Keterbatasan-keterbatasan inilah yang mendorong lahirnya alternatif. GraphQL, misalnya, muncul untuk mengatasi masalah over-fetching dengan membiarkan klien meminta data persis sesuai kebutuhan dalam satu permintaan. Sementara SOAP, gaya yang lebih tua dan formal, masih dipakai di lingkungan yang menuntut aturan ketat. Tabel berikut merangkum posisi ketiganya:
| Aspek | REST | SOAP | GraphQL |
|---|---|---|---|
| Bentuk | Gaya arsitektur | Protokol | Bahasa kueri |
| Format data umum | JSON | XML | JSON |
| Cara ambil data | Tetap per endpoint | Tetap | Ditentukan klien |
| Paling cocok untuk | API web pada umumnya | Sistem enterprise/perbankan | Data kompleks, hemat permintaan |
Meski begitu, untuk sebagian besar kasus umum, REST tetap menjadi pilihan yang paling matang, paling banyak didukung, dan paling mudah dipelajari.
FAQ Singkat Seputar REST API
Apakah REST API sebuah bahasa pemrograman? Bukan. REST adalah gaya arsitektur, bukan bahasa. Anda bisa membangun REST API dengan bahasa apa pun, mulai dari PHP, Python, hingga JavaScript.
Apakah REST API selalu memakai JSON? Tidak wajib, tetapi JSON adalah format yang paling umum karena ringkas. REST juga bisa mengirim data dalam format lain seperti XML.
Apa beda REST dan SOAP secara singkat? SOAP adalah protokol yang lebih ketat dan formal dengan aturan baku, sedangkan REST hanya gaya arsitektur yang lebih ringan dan fleksibel di atas HTTP. REST umumnya lebih mudah dipakai untuk API web modern.
Perlu belajar apa dulu sebelum REST API? Pahami dasar HTTP, metode permintaan (GET/POST/PUT/DELETE), dan format JSON. Dengan bekal itu, konsep REST akan terasa jauh lebih mudah.
Kesimpulan
REST API adalah cara menata API di atas HTTP dengan sekumpulan aturan agar rapi, seragam, dan mudah ditebak. Ia bukan teknologi atau produk, melainkan gaya arsitektur yang memanfaatkan endpoint sebagai alamat resource, metode HTTP sebagai instruksi, dan JSON sebagai bahasa pertukaran data. Kesederhanaan dan sifat stateless-nya membuat REST mendominasi web modern selama lebih dari dua dekade.
Untuk kebanyakan kebutuhan — dari aplikasi ponsel, integrasi pembayaran, hingga layanan data publik — REST masih menjadi titik awal yang paling masuk akal. Namun bila Anda menghadapi masalah data yang boros atau kebutuhan yang sangat spesifik, tidak ada salahnya mempertimbangkan alternatif seperti GraphQL. Semoga artikel ini membantu.
