Upload
fachmipramulia
View
236
Download
2
Tags:
Embed Size (px)
DESCRIPTION
web service adalah merupakan restful restfull rest api soap
Citation preview
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