Ternyata Saya Salah Faham Soal REST
Ternyata saya salah faham soal REST! Walaupun, sebenarnya tidak salah-salah amat. Apa yang saya bayangkan dan saya rasakan ketika memahami REST itu memang beralasan. Cuma, alasan itu ternyata tidak pada tempatnya.
Ternyata, untuk membayangkan REST, kita harus membayangkan seperti kita memakai aplikasi web melalui web browser. Pengguna aplikasi web tidak akan berfikir soal bentuk datanya mau bagaimana, yang penting tahu-tahu tampil di layar. Nah, sekarang pretheli semua tampilan dari aplikasi web itu. Jadilah REST API! Tombol berubah jadi tautan, halaman berubah menjadi JSON. Nah, bayangkanlah bahwa ada satu aplikasi frontend yang bisa mengerti REST API ini. Dalam sekejap, tampilannya kembali. Cuma, tidak bisa dipermak aneh-aneh. Jadi kayak kerjaan programmer frontend males yang semua-semua pake Bootstrap yang nggak mau mikir ketika ngoding. Dengan adanya REST API, programmer-programmer males ini akhirnya bisa dipecatin semua.
Jadi, supaya sebuah API bisa disebut REST, ketika suatu respon HTTP mengembalikan resource, harus dilampirkan juga tautan-tautan yang berhubungan sama resource tersebut. Tidak hanya itu, skemanya juga dikasih juga. Contohnya seperti ini:
{
"class": [ "invoice" ],
"properties": {
"id": "093b941d",
"all_the_other": "fields",
"so_many": "other_fields",
"status": "published"
},
"entities": [
{
"class": [ "items", "collection" ],
"rel": [ "http://acme.com/rels/pay-invoice" ],
"href": "https://api.acme.com/invoices/093b941d/payment_attempts"
}
],
"actions": [
{
"name": "pay-invoice",
"title": "Pay Invoice",
"method": "POST",
"href": "https://api.acme.com/invoices/093b941d/payment_attempts",
"type": "application/json",
"fields": [
{ "name": "invoice_number", "type": "hidden", "value": "42" },
{ "name": "amount", "type": "number" },
{ "name": "stripe_token", "type": "text" }
]
}
],
"links": [
{ "rel": [ "self" ], "href": "http://api.acme.com/invoices/093b941d" },
{ "rel": [ "previous" ], "href": "http://api.acme.com/invoices/a46c437c" },
{ "rel": [ "next" ], "href": "http://api.acme.com/invoices/ca0e7f36" }
]
}Nah, kalau sudah seperti ini artinya sudah jelas. Terang saja REST API bisa berubah sesuka hati. Karena, setiap kali berubah, skemanya juga ikut berubah. Kalau ada service yang diganti, tautan ke service tersebut juga ikut berubah. Ini sebenarnya bukan API lagi. Ini istilahnya application on demand. Aplikasi seperti ini asyik banget kalau tujuan akhirnya adalah untuk dipakai oleh pengguna langsung, di mana aplikasi frontend cukup tipis saja. Tapi, kalau tujuannya untuk dipakai komunikasi antar mesin, jadi menyusahkan karena sifat mesin yang kaku dan deterministik. Bahkan, seandainya REST ini dipakai untuk frontend yang tipis tapi ternyata dibuat menggunakan bahasa statically typed semisal C#, Java, atau C++, tetap saja menyusahkan karena sifat tipe data REST yang dinamis dan baru ada ketika diminta.
Kalau sudah begini, memang wajar kalo REST API itu kemudian jadi banyak menggunakan noun. Coba kalau pake banyak verb, bingung kan jadinya harus digimanain? Tapi, harap diingat bahwa om Phil Sturgeon sudah bilang bahwa REST itu memang cocoknya untuk service yang berbau-bau CRUD. Yang kemarin itu, yang anak SMP saja bisa bikin.
One simple rule of thumb is this:
If an API is mostly actions, maybe it should be RPC.
If an API is mostly CRUD and is manipulating related data, maybe it should be REST.
Dengan demikian, kesalahfahaman saya terhadap REST sudah diluruskan. Kalo kata pakdhe Roy Fielding, REST tanpa HATEOAS bukanlah REST. Jadi, mau itu REST ataupun RPC, itu tergantung permasalahan yang dihadapi. Dan, bagi saya yang programmer OOP, yang namanya (micro)service itu ya kebanyakan RPC, bukan REST.