Status Protokol API pada 2023

• Tren protokol API serta kelebihan/kekurangannya yang dirangkum Postman melalui survei terhadap 40 ribu developer
• REST, WebHooks, GraphQL, SOAP, WebSocket, gRPC, dan lain-lain

REST

• Masih yang paling luas digunakan. Turun dari 92% menjadi 86% dalam 2 tahun terakhir
• Kesederhanaan, skalabilitas, dan kemudahan integrasi dengan layanan web
• Kelebihan REST
  • Kesederhanaan dan standardisasi: Menggunakan metode HTTP standar sehingga mudah diadopsi oleh developer yang sudah akrab dengan HTTP. Kesederhanaannya mendorong pembelajaran dan integrasi yang cepat
  • Skalabilitas: Sifat stateless REST berarti server tidak perlu menyimpan data sesi di antara permintaan. Ini memudahkan penskalaan horizontal dengan menambah instance tanpa perlu server bersama
  • Performa: Respons yang stateless dan dapat di-cache meningkatkan kecepatan eksekusi serta mengurangi jumlah permintaan
  • Modularitas: Layanan RESTful dapat dikembangkan sebagai komponen modular. Ini memungkinkan pembaruan independen dan meningkatkan kemudahan pemeliharaan
  • Tidak bergantung pada platform: Dapat digunakan oleh beragam klien. Interoperabilitas mendorong integrasi API di seluruh sistem
  • Dukungan alat dan komunitas yang matang: Tersedia banyak alat, library, best practice, panduan pemecahan masalah, dan sumber daya komunitas
• Tantangan REST
  • Over-fetching & under-fetching: Klien mungkin hanya membutuhkan sebagian data sehingga bisa mengambil terlalu banyak atau terlalu sedikit data. Ini dapat menimbulkan masalah performa dan membuang bandwidth
  • Banyak antarmuka: Mengambil data yang saling terkait bisa memerlukan banyak permintaan, yang meningkatkan latensi. Rangkaian panggilan ini menjadi masalah saat aplikasi diskalakan
  • Masalah versioning: Membuat versi baru dari REST API bisa merepotkan, terutama ketika struktur data atau fungsi layanan berubah. Ini sering menimbulkan masalah kompatibilitas dengan versi sebelumnya
  • Overhead stateless: Sifat stateless memang mendukung skalabilitas, tetapi juga berarti setiap permintaan harus menyertakan semua konteks yang diperlukan. Ini bisa menimbulkan overhead, terutama jika klien harus mengirim banyak data berulang
  • Kurangnya kemampuan real-time: REST tidak dioptimalkan untuk aplikasi real-time seperti chat atau live feed. WebSocket dan SSE lebih cocok untuk use case ini

WebHooks

• Webhook adalah callback HTTP kustom yang dipicu oleh event di aplikasi sumber
• Saat event terjadi, aplikasi sumber mengirim permintaan HTTP (umumnya POST) ke URI yang ditentukan aplikasi target, sehingga komunikasi berbasis event yang nyaris real-time dapat dilakukan tanpa polling berulang
• Webhook semakin populer, dan 36% developer menggunakannya untuk integrasi mulus antar berbagai sistem
• Kelebihan WebHooks
  • Komunikasi real-time: Webhook memungkinkan pengiriman data secara real-time. Saat event terjadi, data terkait langsung dikirim sehingga sinkronisasi terbaru antar sistem terjaga
  • Efisiensi: Webhook menghilangkan polling yang intensif sumber daya sehingga menghemat performa komputasi dan bandwidth
  • Fleksibilitas: Webhook dapat dikonfigurasi untuk merespons event tertentu, sehingga bisa dikustomisasi tindakan atau trigger apa di satu aplikasi yang akan mengirim data ke aplikasi lain
  • Integrasi yang disederhanakan: Dengan menggunakan metode HTTP, webhook mudah digunakan di sebagian besar aplikasi
  • Mendukung arsitektur terpisah: Karena bekerja berdasarkan event, webhook secara alami mendukung arsitektur event-driven atau decoupled sehingga meningkatkan modularitas dan skalabilitas
• Tantangan WebHooks
  • Penanganan error: Jika sisi penerima webhook down atau terjadi error saat memproses callback, ada risiko kehilangan data. Sistem yang menggunakan webhook perlu memiliki mekanisme penanganan error yang kuat termasuk retry atau logging
  • Masalah keamanan: Webhook mentransmisikan data melalui internet sehingga rentan terhadap penyadapan atau serangan berbahaya. Langkah keamanan API seperti penggunaan HTTPS dan penandatanganan payload sangat penting
  • Mengelola banyak webhook: Manajemen dan pemantauan webhook bisa kompleks. Ini makin terasa saat aplikasi tumbuh dan mulai bergantung pada banyak webhook. Diperlukan perhatian agar semua webhook berfungsi dengan benar dan berbagai endpoint dapat dilacak
  • Potensi overload: Banyak callback simultan dapat membebani aplikasi penerima, tetapi rate limiting atau batch processing dapat membantu menangani lonjakan

GraphQL

• GraphQL adalah bahasa kueri untuk API sekaligus runtime sisi server untuk mengeksekusi kueri menggunakan sistem tipe yang didefinisikan untuk data
• Dikembangkan oleh Facebook pada 2012 dan dirilis sebagai proyek open source pada 2015, GraphQL menawarkan alternatif yang lebih fleksibel dan efisien dibanding REST API tradisional
• Tingkat adopsi GraphQL di kalangan developer meningkat menjadi 29%, menunjukkan pentingnya dalam lanskap API saat ini
• Berbeda dengan REST yang mengharuskan melewati banyak endpoint API untuk mengambil data terkait, GraphQL memungkinkan semua data yang dibutuhkan diambil dalam satu kueri
• Ini sangat berguna bagi developer frontend karena memberi kontrol lebih besar atas proses pengambilan data dan membantu membangun antarmuka pengguna yang lebih dinamis dan responsif
• Kelebihan GraphQL
  • Skema bertipe kuat: API GraphQL memiliki skema bertipe kuat sehingga developer dapat mengetahui dengan tepat data dan tipe apa yang tersedia untuk kueri
  • Pengambilan data yang presisi: Klien dapat meminta data yang tepat dibutuhkan, yang menyelesaikan masalah over-fetching dan under-fetching, sekaligus meningkatkan performa dan menghemat biaya
  • Kompleksitas kueri dan beragam resource: GraphQL mendukung kueri banyak tipe data dalam satu permintaan sehingga jumlah permintaan jaringan untuk data kompleks dan saling terkait dapat dikurangi
  • Update real-time melalui subscription: GraphQL mendukung sinkronisasi real-time melalui subscription sehingga klien dapat diperbarui secara real-time
  • Introspeksi: Skema GraphQL yang terdokumentasi sendiri memudahkan pengembangan melalui pemeriksaan mandiri
• Tantangan GraphQL
  • Kompleksitas kueri: Fleksibilitas yang diberikan GraphQL kepada klien juga punya sisi negatif. Kueri yang terlalu kompleks atau terlalu dalam dapat berdampak buruk pada performa
  • Learning curve: GraphQL memiliki learning curve yang lebih curam daripada REST karena konsep baru seperti mutation dan subscription
  • Versioning: Sifat kueri yang fleksibel berarti perubahan skema bisa merusak kueri yang ada dan membuat versioning menjadi kompleks
  • Potensi penggunaan resource berlebihan: Karena klien dapat meminta banyak resource dalam satu kueri, ada risiko mengambil lebih banyak data daripada yang diperlukan dan membebani server
  • Masalah keamanan: Pengguna jahat dapat menyalahgunakan fleksibilitas GraphQL untuk membebani server dengan kueri yang kompleks

SOAP

• SOAP(Simple Object Access Protocol) adalah protokol untuk pertukaran informasi terstruktur guna mengimplementasikan layanan web
• Menggunakan XML sebagai format pesan dan umumnya menggunakan HTTP atau SMTP sebagai lapisan negosiasi dan transport pesan
• Berbeda dengan REST dan GraphQL, SOAP memiliki standar yang ketat dan fitur bawaan seperti transaksi kompatibel ACID, keamanan, dan pola messaging
• Meski penggunaannya menurun hingga hanya 26% developer, SOAP tetap menjadi pilihan yang andal untuk aplikasi tertentu
• Kelebihan SOAP
  • Typing dan kontrak yang kuat: Memiliki pengetikan kuat dan kontrak yang ketat sebagaimana didefinisikan dalam dokumen WDSL(Web Services Description Language)
  • Fitur keamanan bawaan: SOAP menyediakan keamanan komprehensif melalui autentikasi, otorisasi, dan enkripsi yang diimplementasikan lewat standar WS-Security. Ini membuatnya menjadi pilihan yang disukai untuk aplikasi enterprise
  • Transaksi ACID: SOAP mendukung transaksi ACID yang penting untuk aplikasi dengan integritas data tinggi seperti sistem keuangan atau kesehatan
  • Messaging andal: SOAP menjamin pengiriman pesan yang andal dan menangani error dengan baik sehingga sangat cocok untuk sistem yang membutuhkan jaminan pengiriman pesan
  • Netral terhadap bahasa, platform, dan transport: Seperti REST, layanan SOAP dapat digunakan oleh klien mana pun yang memahami XML, terlepas dari bahasa pemrograman, platform, atau protokol transport yang mendasarinya
• Tantangan SOAP
  • Kompleksitas dan learning curve: SOAP bisa lebih kompleks untuk diimplementasikan karena standar yang ketat dan penggunaan XML, sehingga learning curve-nya lebih curam dibanding alternatif seperti REST atau GraphQL
  • Pesan yang verbose: Header pesan SOAP membawa banyak overhead sehingga payload-nya lebih besar daripada JSON pada REST dan GraphQL. Ini dapat memengaruhi performa dan penggunaan bandwidth
  • Dukungan komunitas terbatas: SOAP mulai kehilangan pijakan, yang berarti dukungan komunitas dan library yang tersedia juga menurun
  • Kurang fleksibel: Jika kontrak berubah, baik klien maupun server mungkin harus memperbarui implementasinya masing-masing, yang bisa menjadi kekurangan
  • Masalah firewall: SOAP dapat menggunakan protokol transport selain HTTP/HTTPS, yang berarti dapat menghadapi pembatasan firewall. Ini membuat SOAP kurang serbaguna pada beberapa lingkungan deployment

WebSocket

• WebSocket menyediakan koneksi dua arah yang persisten dan berlatensi rendah antara klien dan server, sehingga memungkinkan transmisi data real-time
• Berbeda dari siklus request-response HTTP, dengan WebSocket server dapat mengirim data ke klien kapan saja setelah handshake awal
• Ini memudahkan update data instan untuk aplikasi chat, game online, platform trading, dan lainnya
• Menurut survei, 25% developer menggunakan WebSocket
• Kelebihan WebSocket
  • Komunikasi dua arah real-time: Komunikasi dua arah real-time memiliki latensi lebih rendah dibanding koneksi HTTP yang harus dibuat ulang pada setiap pertukaran
  • Overhead lebih rendah: Setelah handshake awal, koneksi tetap terbuka sehingga overhead header yang menyertai permintaan HTTP tradisional berkurang
  • Penggunaan resource yang efisien: Koneksi persisten menggunakan resource server lebih efisien dibanding long polling
• Tantangan WebSocket
  • Kompleksitas implementasi: Implementasi WebSocket bisa lebih kompleks dan memakan waktu dibanding arsitektur API lain, terutama ketika perlu mempertimbangkan fallback di lingkungan yang tidak mendukung WebSocket
  • Kurangnya fitur bawaan: Tidak seperti SOAP yang memiliki fitur bawaan untuk keamanan dan transaksi, WebSocket cenderung low-level sehingga developer harus mengimplementasikan fitur-fitur tersebut sendiri
  • Konsumsi resource: Koneksi WebSocket terbuka umumnya lebih efisien daripada teknik long polling, tetapi tetap mengonsumsi resource server dan bisa menjadi masalah dalam skala besar
  • Batasan jaringan: Beberapa proxy dan firewall tidak mendukung WebSocket, sehingga dapat menimbulkan masalah koneksi di lingkungan jaringan tertentu

gRPC

• gRPC, yang berarti "Google Remote Procedure Call", adalah protokol modern berperforma tinggi yang memudahkan komunikasi antar layanan
• Dibangun di atas HTTP/2 dan memanfaatkan protocol buffers untuk mendefinisikan metode layanan dan format pesan
• Berbeda dengan REST API yang menggunakan kata kerja HTTP standar seperti GET dan POST, gRPC memungkinkan layanan mengekspos metode kustom yang mirip dengan fungsi dalam bahasa pemrograman
• Kelebihan gRPC
  • Performa: Dengan HTTP/2 dan protocol buffers, gRPC dapat mencapai latensi rendah dan throughput tinggi
  • Typing yang kuat: Seperti SOAP dan GraphQL, gRPC bertipe kuat. Akibatnya, tipe dapat divalidasi saat compile time sehingga mengurangi bug
  • Dukungan multi-bahasa: gRPC mendukung berbagai bahasa pemrograman dengan sangat baik, termasuk Go, Java, C#, dan Node.js
  • Streaming: gRPC dapat menangani request dan response streaming secara langsung sehingga cocok untuk use case kompleks seperti koneksi jangka panjang dan update real-time
  • Batteries included: gRPC secara langsung mendukung fitur penting seperti load balancing, retry, dan timeout
• Tantangan gRPC
  • Dukungan browser: Dukungan native browser untuk gRPC masih terbatas, sehingga kurang cocok untuk komunikasi langsung klien-server pada aplikasi web
  • Learning curve: Developer perlu mempelajari cara menggunakan protocol buffers, definisi layanan kustom, dan fitur gRPC lainnya yang dapat menurunkan produktivitas awal
  • Kompleksitas debugging: Protocol buffers tidak dapat dibaca manusia, sehingga lebih sulit untuk melakukan debugging dan pengujian API gRPC dibanding API JSON

Protokol API lainnya

• MQTT : Protokol messaging ringan yang dioptimalkan untuk jaringan ber-bandwidth rendah seperti IoT. Klien dapat mem-publish dan subscribe pesan melalui broker, tetapi beberapa fitur keamanan dan skalabilitas masih kurang
• AMQP : Standar messaging enterprise yang lebih kuat yang menjamin pengiriman pesan andal dan routing pesan yang fleksibel. Namun, ini bisa lebih kompleks dan memiliki overhead lebih besar dibanding protokol ringan
• SSE : Memungkinkan komunikasi satu arah server-ke-klien melalui HTTP, cocok untuk update real-time tetapi tidak memiliki kemampuan dua arah
• EDI : Menstandarkan dokumen elektronik seperti purchase order dan invoice untuk mengotomatisasi komunikasi B2B, tetapi biaya awalnya tinggi dan memerlukan infrastruktur yang kompleks
• EDA : Mendorong arsitektur event-driven di mana komponen bereaksi terhadap event, memungkinkan sistem real-time yang scalable tetapi kompleks untuk di-debug

Kesimpulan

• Lanskap API terus berkembang seiring developer mengadopsi arsitektur, protokol, dan alat baru
• REST masih dominan karena kesederhanaan dan keberadaannya yang luas, tetapi alternatif seperti GraphQL dan gRPC menarik perhatian karena mengatasi masalah seperti over-fetching dan antarmuka yang terlalu cerewet
• Selain itu, developer juga semakin menilai penting WebHooks dan WebSocket karena kebutuhan akan komunikasi real-time
• Untuk banyak use case API umum, REST tetap menjadi pendekatan dasar yang kokoh dengan mempertimbangkan skalabilitas, interoperabilitas, dan kemudahan adopsi. Selain itu, REST juga mendapat manfaat dari kematangan komunitas
• Meski demikian, semua protokol memiliki kelebihan dan kekurangan, dan seiring aplikasi menjadi semakin kompleks, developer secara bijak memperluas toolkit protokol API mereka dengan memasukkan solusi khusus seperti GraphQL dan gRPC
• Daripada mencari satu obat mujarab yang berlaku untuk semua kasus, pengembang API lebih baik memahami kekuatan dan kelemahan dari banyak protokol
• Dengan merancang sistem yang menggabungkan REST, WebHook, WebSocket, GraphQL, dan pendekatan lain yang masing-masing punya keunggulan unik, developer dapat membangun API yang kuat, efisien, dan mudah dipelihara
• Popularitas tiap protokol mungkin akan terus berubah, tetapi tren terpenting dalam lanskap API adalah meningkatnya keberagaman
• Developer harus menerima filosofi multi-protokol ini untuk menciptakan solusi API yang optimal

[zerocyber]

Bagus, saya sudah membacanya.

[test191919]

Kalau bukan pekerjaan yang selesai dengan satu aksi sederhana dan sekali jalan, bukankah transaksi itu wajib? (Saya juga setuju dengan bagian tentang ironi baru sekarang mengarah ke REST padahal itu wajib, haha)