2.2 REST (Representational State Transfer) REST mempersatukan teori tentang bagaimana " distributed hypermedia system " (terutama World Wide Web ) diorganisir dan distrukturkan dengan sebaik mungkin. REST merupakan cara baru berpikir tentang arsitektur jaringan berdasarkan pengamatan atas bagaimana jaringan bekerja. Gambar 2.3 Web dengan Gaya Arsitektur REST (Benson, 2008:128)
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
2.2 REST (Representational State Transfer)
REST mempersatukan teori tentang bagaimana " distributed hypermedia system "
(terutama World Wide Web ) diorganisir dan distrukturkan dengan sebaik mungkin.
REST merupakan cara baru berpikir tentang arsitektur jaringan berdasarkan
pengamatan atas bagaimana jaringan bekerja.
Gambar 2.3 Web dengan Gaya Arsitektur REST (Benson, 2008:128)
2.2.4 Tinjauan Gaya Arsitektural REST
Istilah ini dicetuskan oleh Roy Fielding, salah seorang pencipta spesifikasi HTTP,
pada disertasi doktoralnya pada tahun 2000 yang berjudul “ Architectural Styles and
the Design of Network-Based Software Architectures” . Disertasi tersebut mengekstrak
seperangkat prinsip yang umum yang terdapat pada arsitektur jaringan, berdasarkan
pengujian terhadap struktur jaringan dan protokol HTTP.
REST sering dirujuk sebagai sebuah gaya arsitektural ketimbang sebuah
arsitektur. Ketimbang mendefinisikan sebuah spesifikasi arsitektur terbaik, REST
mendefinisikan prinsip-prinsip yang dengannya arsitektur dibuat dan dievaluasi,
dengan cara meletakkan konstrain-konstrain pada arsitektur jaringan.
Untuk menjelaskan prinsip-prinsip REST, dapat menggunakan analogi yang
dimodelkan pada komunikasi manusia. Nama-nama resource merupakan “kata benda
( noun)”. Penting untuk diingat perbedaan antara resource dan namanya. Sebagaimana
kata “apel”, dimana dirinya sendiri bukanlah apel, nama
http://example.com/person/123 adalah hanya sebuah nama, bukan merupakan
resource. Adalah sesuatu yang wajar bahwa sebuah resource mungkin saja memiliki
banyak nama (walupun style REST yang bagus mengindikasikan bahwa ini
seharusnya dijaga sesedikit mungkin, jika memungkinkan).
Dengan cara yang sama, metoda-metoda HTTP diibaratkan sebagai “ verb”
karena menspesifikasikan sebuah aksi pada sebuah resource atau representasinya.
Tesis Fielding bersifat sangat umum; yang secara aktual dapat diaplikasikan pada
“arsitektur berbasis jaringan” apa saja. Walaupun begitu, penerapan paling
umum dari REST adalah pada World Wide Web dan HTTP. Mau tidak mau, hal ini
mengakibatkan konstrain dan guidelines tidak diturunkan dari tesis Fielding.
Sehingga, prinsip-prinsip yang akan dijelaskan nantinya merupakan subset dari REST
yang didefinisikan oleh Fielding tersebut.
Menurut Ediger(2008:98), REST merupakan penyederhanaan dari HTTP. Dengan
pertumbuhan Web yang semakin populer, banyak keputusan desain asli yang memandu
HTTP diabaikan. Para pengembang aplikasi web cenderung melihat hal-hal
seperti verb HTTP dan kode status respon sebagai sesuatu yang insidental untuk
aplikasi, atau sebagai suatu yang sepele yang akan ditangani jika waktu masih
mengijinkan. Penggunaan HTTP sebagaimana yang diharapkan, sering terlihat sebagai
sesuatu yang tidak diperlukan atau menyulitkan. Namun, dalam beberapa tahun
belakangan ini, dengan hadirnya kembali prinsip-prinsip REST telah mengindikasikan
bahwasanya HTTP telah lebih dari cukup baik di atas segalanya. Para pengembang saat
ini sedang mempelajari beberapa pelajaran berikut ini:
a. Kebanyakan, walupun tidak seluruhnya, setiap domain dapat dengan mudah
dimodelkan sebagai seperangkat operasi CRUD ( Create, Read, Update, Delete ).
Operasi-operasi ini berhubungan dengan metoda POST, GET, PUT, dan
DELETE dari HTTP. Dengan cara ini, seperangkat aksi telah distandardisasikan.
b. Nama seharusnya mengidentifikasi resource , tidak lebih atau kurang. Nama-
nama yang berhubungan dengan resource (contohnya /users/1 ) secara umum
konsisten, robust dan dapat dimengerti. Nama-nama yang berhubungan dengan
service endpoint (seperti /userService) cenderung terlalu luas di luar spesifikasi,
sementara nama-nama yang berkaitan dengan RPC call (seperti /users/create,
ketika diakses dengan POST) adalah redundan (berlebihan). HTTP POST dan
create, kedua-duanya menyatakan pembuatan resource baru. Menurut prinsip
RESTful, frase tersebut seharusnya “ POST /users/1 ”, dimana verb HTTP
menspesifikasikan action dan URI menspesifikasikan objek dari action tesebut.
Tabel 2.1 Perbandingan RESTful dengan RESTless (Non REST)
c. Sebuah resource dapat memiliki multi representasi, tetapi kesemuanya harus
bisa diidentifikasi berasal dari resource yang sama (hal tersebut harus dapat
direfleksikan dari namanya).
Gambar 2.4 Resource dengan Multi Representasi
2.2.2 Keuntungan Arsitektur RESTful
Menurut Ediger(2008:149), beberapa keuntungan dengan diimplementasikannya
Arsitektur REST diantaranya dapat dijelaskan sebagai berikut:
2.2.2.1 Penyederhanaan Konsep
Dasar dari REST adalah kesederhanaan. Keputusan untuk menggunakan seperangkat
verb standar (apakah menggunakan verb HTTP ataupun seperangkat verb lain) secara
virtual mengeliminasi seluruh daerah diskusi. Registrasi yang seragam dan sistem
penamaan MIME type mungkin tidak menyudahi perdebatan, tapi secara pasti
menyederhanakannya.
Dengan dua sudut dari segitiga REST tersebut mendapat perhatian, secara
potensial area abu-abu terbesar adalah mengidentifikasi dan menamai resource.
Penamaan adalah salah satu area dimana kesederhanaan benar-benar dibayar mahal,
karena sangat mudah untuk menjadikannya keliru. Akan tetapi, jika kita benar-benar
mentaati pemakaian seperangkat verb standar dan tipe konten, maka hal itu akan
membantu konstrain pemilihan noun.
Inilah yang dimaksud oleh desainer dan arsitek sebagai “konstrain yang
membebaskan”. Prinsip-prinsip REST diturunkan dari pengamatan terhadap cara kerja
web dan jaringan hypertext lain secara aktual. Ketimbang menetapkan pembatasan
yang berubah-ubah, maka lebih baik membubuhkan cara bagaimana web seharusnya
beraksi.
Dengan bekerja menggunakan prinsip REST, maka setiap kesulitan yang dihadapi
dapat diperlakukan sebagai petunjuk bahwa kita telah melawan butir-butir pembentuk
arsitektur web yang alami. Tapi, sebenarnya masih memungkinkan bahwa kasus
tertentu yang dihadapi merupakan kasus spesial. Beberapa domain aplikasi ada yang
tidak cocok dengan paradigma REST. Tetapi, dengan mencoba menerapkan paradigma
REST akan memaksa seseorang untuk menolak kekecualian apapun dan kasus-kasus
spesial, dan dengan melakukannya maka akan terbukti kekecualian tersebut tidak
diperlukan lagi.
2.2.2.2 Ketahanan dari Perubahan
Keuntungan lainnya yang didapat dari desain RESTful adalah desain cenderung lebih
ulet terhadap perubahan daripada antarmuka bergaya RPC ( Remote Procedure Call ).
Desain RESTful membawa keputusan arsitektural ke dalam daerah noun. Pemilihan
noun cenderung bersifat domain-driven, sementara antarmuka RPC cenderung lebih
implementation-driven, karena prosedurnya (detail implementasi) diekspos sebagai
bagian dari antarmuka. Manakala anatarmuka RPC sering membutuhkan lapisan
tambahan untuk memisahkan antarmuka dengan implementasi, REST mengusahakan
pemisahan antarmuka dan implementasi dengan penganjuran antarmuka yang lebih
abstrak.
Juga, dikarenakan REST membedakan ide “ resource” dari “representasi”,
adalah mudah untuk menambah tipe konten baru yang merepresentasikan resource
yang sama sebagai format baru yang diperlukan. Tidak ada perubahan arsitektural
yang diperlukan, karena REST didasarkan pada pemisahan antara resource abstrak
dan representasinya.
2.2.2.3 Keseragaman
Salah satu keuntungan terbesar yang diberikan oleh guidelines REST adalah
antarmuka yang seragam. Verb (metode HTTP) secara universal seragam, di seluruh
domain aplikasi. Tipe konten, walaupun tidak universal (akan berbeda di sepanjang
domain), sudah distandardisasi dan relatif terkenal.
Fakta bahwa pengembang dibatasi pada seperangkat kecil metode mungkin terlihat
memaksa, tetapi dalam prakteknya bukanlah hal yang terlalu menjadi perhatian. Apa
saja yang ingin dimodelkan dapat dengan mudah disusun dalam bentuk operasi CRUD.
Dengan cara berpikir seperti ini, membantu untuk mendorong kompleksitas yang
esensi ke dalam salah satu bagian arsitektur dimana mudah memperlakukannya.
Biasanya, ketika nampak diperlukan lebih dari metode dasar,
akan ada entiti resource lain yang tersembunyi di dalam model, yang menunggu untuk
diekstrak.
Tipe konten distandardisasi dengan cara yang berbeda. Tipe konten biasanya sesuatu
yang spesifik aplikasi, sehingga tidak akan ada gunanya bersifat universal. Meskipun
demikian, untuk memfasilitasi komunikasi, tipe konten biasanya bersifat
standar. Dalam dunia HTTP, ini diimplementasikan sebagai MIME ( Multipurpose
Internet Mail Extensions ), sebuah standar Internet yang mendefinisikan framework
untuk tipe konten. Seperangkat MIME type bersifat extensible, sehingga aplikasi baru
dapat mendefinisikan tipe lokal dan bahkan mendaftarkannya pada IANA manakala
telah meluas penggunaannya (Benson, 2008:103).
Keseragaman yang diberikan REST sangat membantu usaha standardisasi. Ketika
mengadakan multi sistem secara bersama-sama (sebagaimana terjadi ketika
mengembangkan sebuah standar), semakin sedikit perbedaan yang ada, akan semakin
sedikit pertentangan. Jika setiap orang menstandardisasi pada seperangkat verb (yang
secara universal telah standar ketika menggunakan HTTP), lalu perbedaan yang
tersisa hanya tipe konten (yang secara wajar akan standar di dalam sebuah domain
aplikasi) dan noun.
Oleh karena itu, dengan menyetujui penggunaan antarmuka RESTful membantu
mengurangi problem yang sangat banyak terkait dengan standardisasi terhadap suatu
problem yang dapat lebih diatur melalui perepresentasian data (tipe
konten) dan penamaan sesuatu (noun).
2.2.3 Komponen REST
Menurut Ediger(2008:110), kombinasi dari noun, verb dan tipe konten ini sering
disebut sebagai segitiga REST. Ketiganya, membentuk tiga sudut dari segitiga yang
mendefinisikan arsitektur. Sebuah desain yang berorientasi REST sering bisa
didekomposisikan dengan menentukan noun (pengidentifikasian dan penamaan
sesuatu), memilih seperangkat verb yang seragam (ini mudah dilakukan jika
menggunakan HTTP), dan memilih tipe konten.
2.2.3.1 Verb
Verb berhubungan dengan aksi terhadap resource. Sebuah verb akan mengirimkan
suatu representasi dari sebuah resource dari server ke klien atau memperbaharui
resource di server dengan informasi dari klien.
Di dalam REST, verb merupakan daerah yang penuh dengan konstrain.
Sementara seperangkat tipe konten terbuka untuk revisi dan ekspansi, dan nama-nama
resource dapat diekspansi sampai tak berhingga, sedangkan seperangkat verb sudah
fix (tetap). Namun, setiap konstrain yang diletakkan pada ruang lingkup verb
mengijinkannya untuk bersifat universal, verb apapun dapat diterapkan kepada setiap
noun.
HTTP mendefinisikan serangkaian metoda; yang bisa diperluas oleh protokol lain
seperti WebDAV, tetapi seperangkat dasar sudah cukup untuk REST. Empat metoda
yang paling umum adalah GET, PUT, DELETE dan POST.
Untuk menjelaskannya dapat dibuat beberapa analogi linguistik sebagai
simplifikasi dari empat metode umum. “Ini” akan menunjuk pada request body, dan
“di sana” menunjuk kepada URI dimana ia beraksi.
a. GET: “Berikan aku yang ada di sana”
b. PUT: “Simpan ini di sana”
c. DELETE: “ Hapus yang ada di sana”
d. POST: “Hey kamu yang ada di sana, proses ini”
2.2.3.1.1 GET
Metoda GET mengirim representasi resource dari server ke klien. Ini digunakan
hanya untuk mengakses resource secara read-only. Sejauh ini, GET adalah verb
paling umum di Web dimana website statik sering hanya mempergunakan metode ini.
Gambar 2.5 Metode GET
Kesalahan yang umum dilakukan adalah mempergunakan GET untuk aksi
yang memperbaharui resource (update). GET didefinisikan sebagai metode safe yang
seharusnya digunakan untuk pengambilan ( fetching), bukan update. Pengunaan GET
untuk update dapat menyebabkan banyak problem karena ia telah merusak asumsi
klien dan proxy-proxy yang dilewati terhadap sifat asli request GET.
2.2.3.1.2 PUT
Metoda PUT meng- update resource dengan representasi yang dinyatakan di dalam
body request PUT. Jika resource tidak ditemukan, request akan membuat resource
yang baru dengan representasi yang diberikan.
Sebuah hal umum yang membingungkan adalah bagaimana menentukan nama-
nama resource (URI) apakah diterapkan pada request PUT atau POST. Request PUT
digunakan jika klien mengetahui URI dari resource, yang apabila tidak ada maka akan
dibuat resource yang baru sebagai mana yang sudah ditetapkan pada URI. Jika klien
tidak mengetahui URI dari resource (contohnya, jika ia diambil dari ID yang
dibangkitkan secara otomatis oleh server), maka request POST yang seharusnya
digunakan.
Gambar 2.6 Metode PUT
2.2.3.1.3 DELETE
Sebagaimana diimplikasikan dari namanya, metoda DELETE menghapus resource
yang diidentifikasikan oleh URInya. Jika penghapusan ditolak oleh server yang tidak
mengijinkan penghapusan, subsequent query GET ke URI yang sama harus
mengembalikan kode status 410 ( Gone ) atau 404 (Not Found).
Gambar 2.7 Metode DELETE
2.2.3.1.4 POST
POST disebutkan belakangan karena merupakan perhentian terakhir. Metoda ini tidak
safe, tidak juga idempotent, sehingga ada sedikit pembatasan teknis pada kekuatannya.
Sehingga, sebaiknya tidak menggunakannya untuk operasi-operasi yang dapat lebih
baik direpresentasikan dengan verb lainnya. Secara teoretis, POST bisa digunakan
untuk setiap aksi terhadap Web tanpa merusak RPC.
Walaupun POST powerful, itu tidak seharusnya digunakan dimana GET, PUT, atau
DELETE sudah mencukupi. Semantik dari tiga metoda tersebut lebih sederhana,
dan konstrain-konstrain yang diletakkan padanya mengijinkan caching yang
memudahkan dan skalabilitas. POST bisa, secara teori, di- cache menggunakan header
Cache-Control dan Expires , tetapi pada praktiknya ini jarang diimplementasikan.
POST utamanya digunakan dalam salah satu dari dua cara berikut, penciptaan objek
baru dan pemberian anotasi objek yang sudah ada. Pada kedua kasus tersebut,
URI dari POST adalah kontainer objek tersebut atau parent-nya. RFC
menggambarkannya dengan sebuah analogi dari struktur direktori dimana untuk
membuat atau meng- update sebuah objek, harus mem-POST pada direktori
penampungnya.
Gambar 2.8 Metode POST
Untuk membuat sebuah resource , representasinya dikirim via POST ke sebuah
URI yang bertanggung jawab untuk pembuatan resource dengan tipe tersebut. Jika
request untuk pembuatan sukses, server akan melakukan redirect via header
Location yang menuju URI resource yang sudah dibuat tersebut.
Ketika memberikan anotasi sebuah resource, URI dari POST adalah resource
yang akan dianotasi (“ parent” dari entiti yang akan dikirim). Ini berbeda dari request
PUT, dimana resource yang di-POSTing tidak akan diupdate dengan representasi
yang baru, melainkan dianotasi dengan informasi tambahan.
2.2.3.2 Resource
Konsep paling mendasar dari REST adalah resource. Definisi paling umum dari
resource adalah sesuatu dengan identitas. Dalam pemakaian yang populer digunakan,
istilah “resource ” biasanya berarti sesuatu yang dapat dialamati jaringan pada internet.
Tetapi sebuah resource dapat berupa apa saja, baik itu nyata ataupun yang tidak dapat
diraba, asalkan dapat dinamai. Sebagaimana dijelaskan IETF RFC 2396 (dalam
Ediger, 2008:106):
Sebuah resource dapat berarti apa saja yang memiliki identitas. Contoh yang familiar
termasuk sebuah dokumen elektronik, sebuah gambar, service (contohnya, “laporan
cuaca hari ini untuk Indonesia), dan koleksi dari resource lain. Tidak semua resource
bisa diambil via jaringan; contohnya, manusia, perusahaan, dan setumpuk buku di
dalam perpustakaan dapat juga dikatakan resource.
Tersembunyi di dalam definisi resource ini adalah bahwa resource
mempunyai state (resource bisa saja mempunyai state kosong pada kasus degenerasi,
tetapi ini jarang dijumpai). Salah satu dari konstrain yang menempatkan REST pada
interaksi dengan resource adalah bahwa setiap RESTful resource memiliki antarmuka
yang seragam. Tidak ada klien yang memiliki akses ad-hoc (baca atau tulis) pada
sebuah resource menyangkut state resource , hal tersebut hanya diketahui oleh internal
resource. Setiap akses didapat dengan melalui transfer representasi dari state resource
via seperangkat metoda yang seragam (dalam hal ini, HTTP).
2.2.3.3 Representasi dan Tipe Konten
Resource di Web "hidup" dan menjaga statenya di server, tetapi mereka hanya akan
diakses melalui representasi yang diberikannya. Klien tidak pernah melihat resource
itu sendiri, semua yang dilihat itu merupakan representasi dari resource tersebut.
Sebuah resource dapat memiliki representasi yang berbeda berdasarkan tipe
kontennya. Resource yang sama dapat tersedia melelui user/1.html, user/1.xml,
dan user/1.js. Format nama ini menyatakan bahwa mereka adalah representasi dari
resource yang sama.
2.2.3.3.1 Memilih Representasi
Salah satu rincian yang tidak terspesifikasikan oleh REST adalah bagaimana klien
meminta tipe konten tertentu. Dari banyaknya representasi yang mungkin tersedia dari
resource yang sama, bagaimana cara server mengetahui yang mana yang dikirim?
Dalam prakteknya, jawabannya adalah dengan menggunakan ekstensi URI atau
negosiasi konten. Ekstensi mudah dimengerti dan diimplementasikan: URI diuji
untuk ekstensi nama file seperti .js, .html, atau .xml. Lalu representasi yang paling
cocok kemudian dipilih berdasarkan pada type map (struktur yang memetakan
ekstensi nama file ke tipe konten). Sebagai contoh, permintaan URI
orders/124.html akan mengembalikan:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head>
<title>Viewing Order #124</title> </head> <body id="order-124">