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
(0 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
Nama-

resource

, tidak lebih atau kurang.

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
RESTful, frase tersebut seharusnya

resource baru. Menurut prinsip

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
sesuatu), memilih seperangkat

noun (pengidentifikasian dan penamaan

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.
b.

GET: Berikan aku yang ada di sana

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 namanama 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
Location

redirect via

header

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

orders/124.xml ,

resource yang sama dengan URI berbeda,

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
Language),

request header Accept -

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

(0 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
dengan representasi yang dapat dilayaninya.

request

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.
service juga mempromosikan sebuah visi dari Web dimana situs mampu

Web

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 .

a.

Konsep baru URL ini dapat dijelaskan sebagai berikut:

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

(0 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.
server akan

Ketika satu

request baru tiba di server, maka pertama-tama web

mengecek apakah file-file statik pada direktori / public merupakan respon yang
diinginkan.
b.
diinterpretasikan sebagai lokasi file dalam

Jika ya, URL

filesystem lokal dari

aplikasi web dan konten file akan dikirimkan ke pengguna.

d.
URL tidak sesuai dengan file yang terdapat pada direktori /
maka selanjutnya

request akan ditangani oleh

Jika path
public,

router Rails yang akan

mencocokkan request path dengan route yang diketahui.

e.
Proses
serangkaian definisi
config/routes.rb

routing menggunakan
route pada file
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
Memilih sebuah kelas

controller data,

dan metode dalam kelas tersebutmemo

Format Respon
Header HTTP atau
definisi route (variabel
:0 format)

untuk dieksekusi sebagai respon

difikas

terhadap web request

i data

Menspesifikasikan format respon atau

mengh
dari

action

yang

tersediaapus
data.

Parameter Request
Form data atau
parameter yang diencode pada URL
Perintah HTTP
Request HTTP

Memberikan parameter tambahan

untuk memenuhi request dasar
Menyatakan

request yang

diinginkan, apakah itu mengambil

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
bertindak seperti layaknya programmatic API.

endpoint-endpoint ini juga

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