Dunia pengembangan perangkat lunak secara diam-diam telah bergeser dari arsitektur REST asli milik Roy Fielding, meskipun banyak yang mengklaim membangun API RESTful. Apa yang kebanyakan developer sebut sebagai REST saat ini sangat berbeda dengan prinsip akademis yang diuraikan dalam disertasi Fielding tahun 2000 yang mendefinisikan Representational State Transfer.
Kesalahpahaman Besar tentang REST
Masalah inti terletak pada salah interpretasi fundamental tentang apa sebenarnya arti REST. REST sejati memerlukan HATEOAS (Hypermedia as the Engine of Application State), di mana klien menemukan tindakan yang tersedia secara dinamis melalui tautan hypermedia yang tertanam dalam respons server. Alih-alih melakukan hardcode endpoint API, klien seharusnya menavigasi API seperti pengguna menjelajahi situs web - mengikuti tautan yang disediakan oleh server.
Sebagian besar API REST modern sebenarnya adalah sistem bergaya RPC yang kebetulan menggunakan HTTP verb dan JSON. Mereka memerlukan dokumentasi ekstensif, URL yang di-hardcode, dan kopling ketat antara klien dan server. Pendekatan ini bertentangan dengan visi Fielding tentang sistem yang dapat ditemukan sendiri dan dapat berkembang.
HATEOAS: Prinsip REST yang mengharuskan klien menemukan tindakan API melalui hyperlink dalam respons, bukan mengandalkan dokumentasi
Enam Batasan REST menurut Fielding:
- Gunakan Uniform Resource Identifiers (URIs) untuk semua resource
- Patuhi standar HTTP yang ada tanpa modifikasi
- Definisikan pemahaman data melalui media types dan links, bukan struktur URI
- Client tidak boleh hardcode path URI tetapi harus menemukannya secara dinamis
- Klasifikasi internal server harus tidak terlihat oleh client
- Client hanya membutuhkan satu entry point dan pengetahuan tentang media types standar
Mengapa Developer Memilih Pragmatisme daripada Kemurnian
Komunitas sebagian besar telah menerima penyimpangan ini karena alasan praktis. Membangun API yang benar-benar RESTful dengan HATEOAS menciptakan overhead dan kompleksitas yang signifikan yang dianggap tidak dapat dibenarkan oleh banyak tim. Beban kognitif dalam menciptakan klien yang digerakkan hypermedia seringkali lebih besar daripada manfaat teoretis dari loose coupling dan evolvability.
Adopsi luas dari gaya yang lebih sederhana mirip RPC melalui HTTP kemungkinan dapat dikaitkan dengan trade-off praktis dalam tooling dan pengalaman developer.
Tools seperti OpenAPI dan Swagger telah memudahkan untuk menghasilkan kode klien, membuat dokumentasi, dan memvalidasi permintaan untuk API HTTP tradisional. Keuntungan produktivitas langsung ini terbukti lebih berharga bagi sebagian besar tim daripada manfaat arsitektur abstrak dari REST murni.
Karakteristik Umum API "REST" (Sebenarnya Tidak RESTful):
- JSON melalui HTTP dengan operasi CRUD
- Dipetakan ke verb POST/GET/PUT/DELETE
- Template URI yang dikodekan keras seperti
/users/{id}/orders - Memerlukan dokumentasi API yang ekstensif
- Kopling ketat antara klien dan server
- Tidak ada kontrol hypermedia atau penemuan tautan
Pengecualian Browser
Menariknya, implementasi paling sukses dari prinsip REST terjadi setiap hari melalui browser web. Ketika Anda mengklik tautan di situs web, Anda sedang mengalami HATEOAS dalam aksi - browser menemukan tindakan yang tersedia melalui hyperlink tanpa pengetahuan sebelumnya tentang struktur situs. Ini berhasil karena manusia menyediakan kecerdasan untuk menafsirkan dan menavigasi hypermedia.
Namun, model human-in-the-loop ini tidak dapat diterjemahkan dengan baik ke komunikasi mesin-ke-mesin, di mana klien otomatis memerlukan antarmuka yang dapat diprediksi dan terdokumentasi dengan baik untuk berfungsi dengan andal.
Bergerak Maju dengan Terminologi yang Jujur
Alih-alih melanjutkan pertarungan semantik tentang definisi REST, banyak developer sekarang lebih suka menyebut kreasi mereka sebagai HTTP API atau JSON API. Pelabelan yang jujur ini menghindari beban akademis sambil dengan jelas mengkomunikasikan apa yang sebenarnya disediakan sistem.
Industri pada dasarnya telah memberikan suara dengan keyboard mereka, memilih solusi praktis daripada kemurnian arsitektur. Meskipun para puritan mungkin menyesali penyimpangan dari visi Fielding ini, adopsi luas API REST-ish menunjukkan bahwa mereka lebih melayani kebutuhan pengembangan dunia nyata daripada rekan-rekan mereka yang secara akademis benar.
Referensi: Most RESTful APIs aren't really RESTful