Memandang Web Service dengan kacamata REST

Seorang insinyur perangkat lunak itu, yang paling utama dia harus bisa menyelesaikan masalah. Alat apa yang dipakai untuk menyelesaikan masalah itu nomer dua, tergantung situasi dan kondisi. Saya sering lupa sama prinsip ini, karena itu harus selalu mengingatkan diri sendiri. Belakangan ini, saya belajar sedikit soal FP. Kalau soal OOP, anggap saja sudah lumayan terkuasai. Dengan dua macam cara berfikir ini, kemudian saya mencoba memahami hakikat dari REST-ful API yang sebenarnya. Akan tetapi, baik melalui paradigma FP maupun OOP, saya gagal memahami mengapa banyak orang tergila-gila dengan konsep abstrak yang dicetuskan lebih dari dua puluh tahun yang lalu.

Apakah gagal faham ini dikarenakan REST-ful API itu arsitektur dan bukan paradigma? Bisa jadi. Untuk memperluas pemahaman saya soal arsitektur perangkat lunak, saya mempelajari ide-ide dari actor pattern, entity component system, MVVM, dan The Elm Architecture. Untuk memperdalam fondasi concurrent programming saya, saya belajar soal async / await, channels di Go, dan message queue. Tentu saja juga belajar soal mutex, lock, condition variable, memory order, dan lock free programming walaupun masih belum mengerti sampai sekarang. Lalu sekarang saya dihadapkan dengan REST. Pakai cara pandang apapun, saya tetap bingung bagaimana harus menempatkan REST.

Baik, marilah kita coba menganalisis REST ala OOP. Bukannya REST itu suka banget sama nouns? Harusnya, REST itu cocok sama OOP dong. Permasalahannya ternyata tidak demikian. REST itu sering sekali diimplementasikan dalam sistem besar yang terdiri dari banyak aplikasi-aplikasi kecil yang berdiri sendiri yang dinamakan microservices. Kalau saya memandang sebuah microservice, maka saya akan memandangnya sebagai sebuah objek. Maklum, OOP sudah terlalu terpatri dalam otak saya. Nah, sekarang dari microservice ini, saya ingin membuat REST API-nya. Ternyata tidak bisa! Sebuah sistem yang saya sudah tahu bagaimana membuat interface-nya dan bagaimana data yang akan dikirim dan diterima, ketika mau ditumpangkan di atas HTTP, ternyata tidak nyambung sama sekali kalau pakai REST API.

Mungkin saya salah mengerti soal REST. Mungkin, referensi saya harus diperdalam lagi. Baiklah saya baca-baca lagi soal REST. Saya baca lagi soal kritik terhadap REST, lalu saya baca juga soal bantahannya dari pendukung REST, terakhir saya juga baca bantahan atas bantahannya. Saya ingin sekali membaca disertasinya Pakdhe Roy, tapi setelah membaca artikel di blognya, saya menyerah. Kata-katanya terlalu abstrak untuk saya mengerti. Artinya, kalau mau merancang sebuah backend service, saya tidak akan memakai cara REST. Saya tidak akan melakukan hal yang tidak saya mengerti. Itu namanya goblok kuadrat. Sudah tahu gak faham, eh masih tetap dilakukan juga.

Mari kita coba sekali lagi. Mungkin tadi pendekatannya yang salah. Harusnya, kita merancang sistem itu sedari awal harus REST-ful, tidak bisa cuma ditempel API-nya saja. Tapi, harap diketahui bahwa saya protes berat kalau ada orang merancang REST itu cuma sekedar membuat ulang SQL memakai HTTP. Mau SELECT, ya pake GET dikasih query string. Mau SELECT satu saja, artinya path paling adalah ID yang biasanya jadi klausa dari WHERE. Mau UPDATE, ya pake PUT atau PATCH. Lebih canggih sedikit, bisa memakai JSON Patch. Mau INSERT, ada yang namanya POST. Kalau seperti ini, anak SMP juga bisa. Rugi dong, dikasih gaji jauh di atas UMR kalau cuma ngerjain kayak gini. Yang rugi perusahaannya, bukan programmernya.

Artinya, service yang REST-ful haruslah membedakan antara apa yang dikirim dan diterima oleh client dan apa yang sebenarnya disimpan di database. Kalau sudah begini, ini jelas bukan OOP. OOP itu interaksi antara satu interface dengan interface yang lain melalui method atau sering disebut dengan message. REST memang ada method-nya. Ada GET, POST, PUT, PATCH, sama DELETE. Tapi, masa programmer OOP disuruh menganalisis sistem cuma dengan 5 method saja, ya bagaimana tidak sakit kepala? Artinya, kalo ingin menganalisis REST ala OOP, saya harus membuat banyak sekali noun. Kalau tidak ada noun yang memadai, terpaksa harus memakai POST dengan noun-nya adalah nama data yang akan dikirim.

Atau, mungkin saya salah menganalisis REST secara OOP? Baiklah, kalau begitu saya akan coba menganalisis ala FP. Duh, padahal juga baru mulai belajar ini. Kalau saya membayangkan web service ala FP, maka setiap request dan response itu ibarat sebuah fungsi. Fungsi ini mengirim request sebagai parameter, dan mengembalikan response setelah selesai dieksekusi. Nah, kalau orang merancang program ala FP, biasanya lama di bagian struktur data atau type-nya. Type ini bolehlah dianalogikan dengan resource di REST. Dan, memang biasanya akan muncul banyak type dari hasil rancangan ini. Dari sini, kelihatannnya REST lebih enak dianalisis secara fungsional. Tapi, ya tidak lima fungsi juga kali! Justru, fungsi-fungsi di FP itu banyak sekali. Kosakata method HTTP tidak cukup untuk merancang sebuah web service ala FP.

Kalau saya lihat, baik FP maupun OOP peran fungsi itu sangat penting. Ya, kalau tidak programnya tidak bisa jalan! Paradigma FP memisahkan antara tipe data dan fungsi dan menganalisis keduanya secara independen. Kegiatan utamanya adalah memanipulasi fungsi agar bisa tersambung satu dengan yang lainnya dan merancang tipe-tipe data yang sesuai dengan problem domain. Berbeda dengan OOP, kegiatan utamanya adalah merancang interface supaya satu objek dengan objek yang lain bisa saling bertukar pesan melalui fungsi, sementara data yang sebenarnya disembunyikan di balik objek. Dalam dua paradigma ini, memecah masalah menjadi kecil-kecil adalah salah satu teknik utama untuk menganalisis permasalahan. Sehingga, harusnya tidak masalah jika REST API itu nanti terpecah-pecah menjadi banyak nouns. Bagi FP noun itu tipe data, bagi OOP itu adalah objek.

Akhirnya, saya berpendapat bahwa merancang API yang REST-ful itu ibarat disuruh memasak dodol dengan tangan terikat. Susah dan lama. Dengan adanya verb yang terbatas, maka harus kreatif membuat-buat nouns yang sebenarnya tidak perlu ada. Untuk mengakses sistem melalui jaringan, bagi saya protokol ringan ala JSON-RPC sudah cukup. Dengan begitu, saya bebas menganalisis permasalahan dengan teknik-teknik yang saya tahu, dan itu bukan dengan cara REST. Eh, tunggu sebentar, ada kasus di mana REST sangat cocok menyelesaikan permasalahan dengan 5 method saja. Itu adalah CRUD! Ya, tidak apa-apa sih kalau kita dibayar gaji engineer unicorn untuk mengerjakan pekerjaan anak SMP. Santai gitu kerjanya.