Belajar menilai seberapa sempurna rancangan REST API


Membuat API berbasis REST pada dasarnya adalah sesuatu yang sangat mudah: buat sebuah method di controller dan kembalikan hasil berupa JSON. Selesai! Yup, cukup sampai disini bagi programmer yang sedang belajar atau membuat proyek jangka pendek yang tidak ingin berkembang. Pada tulisan kali ini, saya akan melihat dari sisi arsitektur, dimana REST API tersebut akan dipakai dalam jangka lama dan mungkin akan dipanggil oleh klien baru yang belum terpikirkan saat ini.

Salah satu cara untuk menilai implementasi REST API adalah dengan membandingkannya dengan Richardson Maturity Model. Gambar berikut ini memperlihatkan perkembangan REST menurut model tersebut:

Richardson Maturity Model

Richardson Maturity Model

Pada Level 0, REST API dianggap sebagai API jarak jauh yang dipanggil melalui Web (Http) dan mengembalikan JSON. Tidak lebih dari sekedar pengganti function atau method (yang dikerjakan jarak jauh)! Sebagai contoh, API berikut ini masuk dalam kategori Level 0:

POST http://api.server.com/buatProduk
{
   nama: "produk1",
   harga: 1000
}

POST http://api.server.com/hapusProduk
{
   id: 1
}

POST http://api.server.com/daftarPelanggan
{
   email: "ocelat@dd.com",
   nama: "ocelot"
}

POST http://api.server.com/hapusPelanggan
{
   id: 1
}

Pada Level 1, terdapat konsep resource. Setiap API merupakan operasi yang akan melakukan sesuatu pada resource yang ada. Sebagai contoh, API berikut ini termasuk dalam kategori Level 1:

POST http://api.server.com/produk/buat
{
   nama: "produk1",
   harga: 1000
}

POST http://api.server.com/produk/hapus
{
   id: 1
}

POST http://api.server.com/pelanggan/daftar
{
   email: "ocelat@dd.com",
   nama: "ocelot"
}

POST http://api.server.com/pelanggan/hapus
{
   id: 1
}

Pada contoh di atas, setiap API masih dipanggil dengan request POST yang populer dari dulu. Biasanya, GET dipakai bila kita tidak ingin mengirim data tambahan seperti JSON. Bila ingin mengirimkan JSON atau mengirim data dalam jumlah besar, POST akan digunakan. Padahal selain GET dan POST, HTTP juga memiliki request method lainnya seperti HEAD, PUT, DELETE, TRACE, OPTIONS, CONNECT, dan PATCH.

Sebuah request yang sukses akan mengembalikan respon 200. Selain respon 200, HTTP juga memiliki definisi response status code yang lain seperti 500 untuk menandakan kesalahan, 201 untuk menandakan resource berhasil dibuat, dan sebagainya.

Pada Level 2, REST API akan memanfaatkan HTTP request method dan response status code. Sebagai contoh, API berikut ini masuk dalam kategori Level 2:

POST http://api.server.com/produk
{
   nama: "produk1",
   harga: 1000
}

PUT http://api.server.com/produk/1
{
   nama: "produk1 dengan nama baru",
   harga: 2000
}

DELETE http://api.server.com/produk/1

POST http://api.server.com/pelanggan
{
   email: "ocelat@dd.com",
   nama: "ocelot"
}

DELETE http://api.server.com/pelanggan/1

Pada Level 3, REST API akan menggunakan HATEOAS. Sebagai contoh, saya membuat REST API yang mendukung HATEOAS di artikel Membuat RESTFul Web Service Dengan Spring Data REST. Kenapa memakai HATEOAS? Beberapa keuntungan yang ditawarkannya antara lain:

  1. Klien tidak perlu men-hardcode link untuk melakukan operasi terhadap resource yang diterima.  Dengan demikian, perubahan nama atau lokasi API tidak menimbulkan perubahan di kode program klien.
  2. Klien dapat mengetahui operasi apa yang diperbolehkan dan tidak diperbolehkan terhadap resource.   Sebagai contoh, pada UI yang berisi daftar produk, bila tidak ada link untuk menghapus produk yang dikembalikan bersamaan dengan produk tersebut (misalnya karena user yang login tidak berhak untuk operasi tersebut), maka saya bisa menyembunyikan tombol hapus.

Sayangnya, hingga saat ini tidak ada implementasi yang standar untuk HATEOAS.  Salah satu yang menjanjikan adalah HAL (Hypertext Application Language).  Daftar library yang mengimplementasikan HAL dapat dijumpai di https://github.com/mikekelly/hal_specification/wiki/Libraries.

REST API dari Paypal dan Netflix adalah contoh API yang sudah mendukung HATEOAS.  Sementara itu, kebanyakan penyedia REST API publik lainnya hanya berada pada Level 2 karena mereka berfokus pada kemudahan penggunaan (sementara HATEOAS tidak begitu populer).   Perlu diingat ini bahwa mereka adalah API publik yang ditujukan untuk dikonsumsi oleh developer luar dari berbagai kalangan.  Fokus ini tentu akan berbeda, misalnya, pada saat merancang arsitektur microservices untuk dipakai dalam perusahaan.

Iklan

Perihal Solid Snake
I'm nothing...

Apa komentar Anda?

Please log in using one of these methods to post your comment:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: