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">

<h1>Order #124</h1> <p>Items:</p> <ul id="order-124-items">

<li><a href="/orders/124/items/1">Office Chair, Medium</a></li> <li><a href="/orders/124/items/2">Ergonomic Keyboard</a></li>

</ul> </body> </html>

Tetapi, permintaan kepada resource yang sama dengan URI berbeda,

orders/124.xml , dapat menghasilkan versi XML yang lebih machine-readable:

<Order id="124"> <Items>

<Item id="1" href="/orders/124/items/1">Office Chair, Medium</Item> <Item id="2" href="/orders/124/items/2">Ergonomic Keyboard</Item>

</Items> </Order>

Representasi JavaScript orders/124.js mungkin menggunakan JSON:

{"order": { "id": 124, "items": [

{"id": 1, "href": "/orders/124/items/1", "description": "Office Chair, Medium"}, {"id": 2, "href": "/orders/124/items/2",

"description": "Ergonomic Keyboard"}] }}

Pengubahan tipe konten berdasarkan pada ekstensi URI adalah cara yang baik dan

mudah, dan ini berjalan baik seiring dengan cara kita memandang Web bekerja secara

tradisional. Selain itu, ini membuat URI terlihat seperti nama file, dan

bertindak layaknya filesystem path. Akan tetapi, ini tidak selalu optimal dalam model

REST.

Semua ini adalah jelas-jelas representasi yang berbeda dari resource yang

sama, dan dengan URI yang berbeda. Banyak yang berpendapat bahwa URI

seharusnya hanya menamai resource, dan tidak representasi. Tetapi bagaimana

mungkin menggunakan nama yang sama untuk mengacu pada semua representasi dari

resource ini?

Jawabannya adalah negosiasi konten. Ini adalah bagian dari request dan

response HTTP dimana klien dan server bernegosiasi mengenai parameter yang

digunakan sehingga mereka dapat berkomunikasi.

Secara keseluruhan, negosiasi konten HTTP sangat fleksibel dimana ia dapat

menegosiasikan representasi berdasarkan bahasa (melalui request header Accept -

Language), karakter encoding (melalui header Accept-Charset), encoding konten

( Accept-Encoding), atau tipe konten ( Accept). Biasanya yang terakhir yang sering

digunakan.

Ketimbang menetapkan tipe konten secara eksplisit pada URI, maka lebih baik

menentukan header Accept pada request HTTP. Header ini berisi daftar tipe konten

yang diinginkan untuk diterima, yang prioritasnya dalam urutan menurun. Dengan

menggunakan negosiasi konten, request ini akan mengembalikan versi HTML:

GET /orders/124 HTTP/1.1 Host: www.example.com Accept: text/html, application/xhtml+xml, text/*, image/png, image/*, */*

Klien dapat memvariasikan header Accept untuk meminta representasi

berbeda dari resource yang diminta, dan server akan berusaha memenuhi request

dengan representasi yang dapat dilayaninya.

Pemilihan representasi menggunakan ekstensi URI atau negosiasi konten

header Accept adalah keputusan yang benar. Keduanya mempunyai keuntungan dan

kekurangan masing-masing, dan Rails mendukung keduanya.

2.3 Web Service

Penyediaan service pada aplikasi web yang dibuat menjadi penting dalam mencapai

kesuksesan. Ini memberikan pengguna kontrol yang lebih baik terhadap data yang

disediakan situs dan membuka pintu kreatifitas guna-ulang dari data tersebut. Web

service juga mempromosikan sebuah visi dari Web dimana situs mampu

menspesialisasikan fokusnya dan bekerjasama dengan lebih efisien dalam mencapai

tujuan pemrograman. Contohnya, sekarang pengembang Web lebih cenderung

menggunakan salah satu peta ( map) yang ditawarkan Google, Yahoo! Atau Microsoft

ketimbang membuat sendiri petanya. Dalam area teknologi manapun, guna-ulang

komponen dan kemampuan untuk spesialisasi merupakan faktor kunci dalam meraih

kemajuan. Penggunaan dan pengembangan service pada Web memungkinkan

peningkatan kualitas dan pengalaman aplikasi web untuk semua pengguna.

Rails dalam hal ini telah menyediakan gaya yang khas dalam mendesain

service dimana seorang pengembang dipaksa untuk mendesain website dan web

service sekaligus dalam satu usaha ketimbang sebagai dua hal yang terpisah dan

komponen yang berbeda dari aplikasi web. Untuk itu, terdapat dua ide cemerlang yang

akan mengubah cara mendesain dan membuat web service.

2.3.1 URL yang Mengalamati Konsep, Bukan File

Dahulu, URL beroperasi pada lapisan abstraksi yang disediakan oleh file system fisik

(file dan direktori), tetapi sekarang URL dioperasikan dalam satu lapisan abstraksi

baru yang ditambahkan di atas aplikasi dan digunakan sebagai ruang yang dapat

dialamati. Dahulu, walaupun kode aplikasi dan strukturnya berarti bagi pengembang,

tapi itu tidak berarti bagi pengguna. Sekarang dengan adanya lapisan abstraksi baru ini,

maka URL bisa terlihat “cantik” dan berarti bagi pengguna juga. Ini misalnya terdapat

pada Flickr, URL akan berbentuk seperti di bawah ini: http://flickr.com/photos/deritaf

URL ini bisa dibandingkan dengan URL pada masa dahulu, misalnya URL

berikut ini yang menunjuk pada merchandise Dr.Seuss dari situs Amazon pada

tanggal 2 Maret 2000 yang didapatkan dari Internet Archive:

http://s1.amazon.com/exec/varzea/search-handle-url/ref=gw_m_col_7/?

index=fixed-price%26rank=-price%26field-status=open%26field-browse=

68457%26field-titledesc%3DDr.%20Seuss .

Konsep baru URL ini dapat dijelaskan sebagai berikut:

a. URL dipandang sebagai alamat menuju ruang-konsep dalam aplikasi ketimbang

sebagai alamat menuju kode di dalam aplikasi. URL ini mungkin

merepresentasikan noun ( resource yang diatur oleh aplikasi) dan verb ( action

pada resource-resource tersebut). URL merupakan entiti yang berarti walau

tanpa parameter apapun, tetapi parameter tetap dapat digunakan untuk

mengklarifikasi dan menambahkan parameter tambahan terhadap request.

b. URL yang dipetakan menuju ruang-konsep aplikasi benar-benar direncanakan

( engineered), sebagaimana halnya dengan interface objek pada bahasa

pemrograman Java dan C++. Struktur dari URL harus mengikuti pola-pola yang

mudah dibaca dan dimengerti. Pola-pola ini dituliskan dan dipaksakan sebagai

bagian dari aplikasi web.

c. Kecuali konten statik, maka tidak terdapat hubungan antara URL dengan file di

web server. URL mengalamati lokasi dalam ruang-konsep, di filesystem. Suatu

langkah yang disebut “ routing” akan terjadi manakala sebuah web request

diterima yang akan mengambil alamat konseptual ini dan memutuskan bagian

mana dari kode aplikasi yang akan digunakan untuk menjawab request tersebut.

2.3.2. Aplikasi Sebagai Service

Setiap kali suatu halaman pada situs dimuat, halaman tersebut merupakan merupakan

respon terhadap suatu request service . Fakta bahwa halaman web tersebut dirender

dalam HTML adalah hanya karena itu merupakan tipe respon dari request service

tersebut. Informasi yang direpresentasikan oleh halaman web tersebut dapat juga

direpresentasikan dengan baik dalam bentuk file teks, XML, RDF atau format lainnya

yang dipilih.

Jika ide sebelumnya diikuti dimana URL seharusnya merepresentasikan konsep

ketimbang file, maka ini berarti pengembang sudah mendefinisikan

“antarmuka” bagi service, serangkaian konsep yang akan membuat website tersedia

bagi penggunanya. Sekarang tinggal mengimplementaikan back-end yang mampu

merespon terhadap request non-HTML pada endpoint URL yang sama.

2.3.3 Routing

Routing memainkan peran kunci yang memungkinkan pengembangan web service ini

pada Rails. Routing adalah sebuah proses dimana request HTTP yang datang

dipasangkan/dicocokkan dengan suatu bagian tertentu dari kode, yang dalam hal ini

merupakan sebuah action pada controller yang akan merespon terhadap request

tersebut. Pada proses ini, Rails akan melakukan scan terhadap URL request yang

datang untuk dicocokkan dengan serangkaian route yang dispesifikasikan dalam file

config/routes.rb di dalam project.

Gambar 2.9 Proses yang Terjadi Ketika Request HTTP Datang

Berikut ini penjelasan bagaimana proses routing ini bekerja:

a. Ketika satu request baru tiba di server, maka pertama-tama web server akan

mengecek apakah file-file statik pada direktori / public merupakan respon yang

diinginkan.

b. Jika ya, URL diinterpretasikan sebagai lokasi file dalam filesystem lokal dari

aplikasi web dan konten file akan dikirimkan ke pengguna.

d. Jika path URL tidak sesuai dengan file yang terdapat pada direktori / public,

maka selanjutnya request akan ditangani oleh router Rails yang akan

mencocokkan request path dengan route yang diketahui.

e. Proses routing menggunakan serangkaian definisi route pada file

config/routes.rb yang dibuat pengembang untuk mendefinisikan endpoint

URL dimana aplikasi web akan merespon. Setiap route merupakan pola yang

akan diisi. Route diperiksa dengan urutan kemunculannya pada file

routes.rb dimana yang pertama kali muncul yang cocok dengan path request

akan menjadi penentu bagaimana request yang datang tersebut ditangani.

Gambar 2.10 Contoh Definisi Route

Karena file routes.rb merupakan penghubung yang menjembatani antara

semua request web non-statik dengan kode aplikasi, maka jelaslah bahwa desain URL

adalah langkah yang sangat terencana ( engineered) dari sejak awal pengembangan

aplikasi web dimulai dan merupakan langkah yang eksplisit harus dilakukan pada

pengembangan aplikasi Rails. Halaman web manapun harus memiliki sebuah URL

yang telah didefinisikan dengan sebuah route. Route-route ini merepresentasikan

antarmuka publik dari sebuah service, walaupun jika service tersebut hanya

mengembalikan halaman HTML. Dalam sebuah API, metode yang protected dan

private yang menyelesaikan tugas/pekerjaaan level rendah benar-benar tersembunyi

dari pengguna API. Demikian juga dalam web service dengan route, struktur file

aktual aplikasi web yang mengerjakan tugas/pekerjaan benar-benar tersembunyi dari

pengguna. Ini merupakan sebuah pemisahan yang lengkap antara file yang

menyebabkan aplikasi web berjalan dan pola URL yang menyediakan akses terhadap

fungsionalitas tersebut.

2.3.4 Anatomi Pemanggilan Web Service

Adanya Routing URL, memungkinkan bagi API berbasis HTTP yang user-friendly

dan mengizinkan URL untuk merepresentasikan endpoint virtual di dalam sebuah

fungsionalitas aplikasi. Endpoint-endpoint ini saja tidak cukup untuk

menspesifikasikan pemanggilan web service secara sempurna melainkan diperlukan

empat komponen yang berbeda.

Empat komponen ini, seperti dideskripsikan pada tabel di bawah ini, terlihat hampir

mirip dengan komponen-komponen pada pemanggilan metode tradisional, dengan

beberapa kekecualian. Fungsi pemanggil dapat meminta tipe pengembalian, dan sebuah

perintah HTTP diberikan bersamaan dengan metode pemanggilan sebagai potongan

data yang akan memandu eksekusi metode tersebut.

Tabel 2.2 Komponen pada Pemanggilan Web Service Komponen Disediakan Oleh Tujuan Controller dan Action Definisi route

Format Respon Header HTTP atau

definisi route (variabel

: format)

Parameter Request Form data atau

parameter yang di-

encode pada URL

Perintah HTTP Request HTTP

Memilih sebuah kelas controller

dan metode dalam kelas tersebut

untuk dieksekusi sebagai respon

terhadap web request

Menspesifikasikan format respon

dari action yang tersedia

Memberikan parameter tambahan

untuk memenuhi request dasar Menyatakan request yang

diinginkan, apakah itu mengambil

data,

memo

difikas

i data

atau

mengh

apus

data.

Ketika mendefinisikan route, ini merupakan konteks yang lebih luas dimana

mereka akan saling sesuai. Website merupakan koleksi dari endpoint-endpoint,

masing-masingnya didefinisikan dan diakses menggunakan empat komponen dalam

tabel di bawah. Biasanya, endpoint-endpoint ini dilayani dalam HTML, tetapi karena

klien dapat me- request format respon yang lain, maka endpoint-endpoint ini juga

bertindak seperti layaknya programmatic API.

2.3.5 RESTful Routing

Dengan adanya routing, aktivitas CRUD pada resource dapat distandarkan dan

dicocokkan dengan protokol HTTP dimana pada HTTP juga terdapat aktivitas yang

serupa dengan CRUD. Terdapat metode-metode standar HTTP, yang dalam hal ini

adalah GET, POST, PUT, DELETE yang akan dipetakan dengan action-action standar

dalam controller. Untuk memungkinkan routing seperti ini, maka perlu ditambahkan

sebaris kode map.resource :nama_resources pada file konfigurasi routes.rb.

Dengan adanya pernyataan seperti itu pada routes.rb, maka Router akan menangani

request HTTP yang datang untuk dipetakan/diarahkan pada resource yang sesuai. Ini

ditunjukkan pada tabel dibawah ini.

Tabel 2.3 Routing Setiap Metode HTTP dengan Action pada Controller

Penjelasan yang lebih definitif ditunjukkan pada Gambar 2.11.

Gambar 2.11 Pemetaan Resource dengan Request pada Router