BAB 2 TINJUAUAN TEORITIS

BAB 2

TINJUAUAN TEORITIS

2.1 Rails

Ruby on Rails atau sering disingkat Rails merupakan sebuah framework aplikasi web full-stack yang ditulis menggunakan bahasa pemrograman Ruby. Aplikasi web adalah perangkat lunak aplikasi yang diakses menggunakan web browser melalui sebuah jaringan (internet). Sedangkan framework dapat dipandang sebagai fondasi dari aplikasi web yang menangani sebagian besar detail level-bawah yang bersifat repetitif dan membosankan dalam menuliskan kodenya, sehingga pengembang dapat fokus pada pembangunan fungsionalitas aplikasi. Full-stack menunjuk kepada luasnya fungsionalitas yang dapat diberikan oleh framework Rails mulai dari penanganan antarmuka pada klien sampai urusan database di server. Sedangkan Ruby adalah sebuah bahasa scripting berorientasi objek yang diciptakan pertamakali oleh Yukihiro Matsumoto pada awal 1990-an (Lenz, 2008:2).

Berikut beberapa prestasi yang telah berhasil diraih oleh framework web ini: a. Rails memenangkan Jolt Award tahun 2006 sebagai perkakas pengembangan web terbaik. b. Buku “Agile Web Development with Rails” terbitan The Pragmatic Programmers menerima penghargaan Jolt Award 2006 untuk kategori buku teknik terbaik. c. Penemu Rails, David Heinemeier Hansson diberi gelar sebagai Hacker of the Year pada OSCON 2006. d. Banyak tokoh-tokoh programmer yang beralih dari PHP dan Java ke Rails, seperti James Duncan Davidson (pengembang Tomcat dan Ant) dan Bruce Tate (pengarang buku-buku Java). e. Rails telah menjadi salah satu framework yang paling berpengaruh dalam pengembangan aplikasi web dengan banyaknya framework web lain yang

Universitas Sumatera Utara

menggunakan filosofi dan arsitektur Rails, seperti Merb, Django, Grails, CakePHP, Code Igniter, JBOSS Seam, ASP.NET dll.

2.1.1 Sejarah Ruby on Rails

Ruby on Rails berasal dari ekstraksi sebuah aplikasi manajemen proyek, Basecamp, yang dikembangkan oleh pengembang web dari Denmark, David Heinemeier Hansson, untuk perusahaan 37signals. David merilis Rails ke publik untuk pertamakalinya pada Juli 2004 sebagai perangkat lunak open source, dan dilanjutkan dengan rilis versi 1.0 pada 13 Desember 2005. Sekarang Rails telah mencapai versi 2.2 yang dirilis pada November 2008 dan di-maintenance oleh Rails Core Team dibantu dengan patch dan bugfix dari jutaan komunitas pengguna Rails. (Lenz,2008:4)

2.1.2 Prinsip-Prinsip Pengembangan

Menurut Lenz(2008:5), Rails mendukung beberapa prinsip pengembangan perangkat lunak yang membuatnya dapat terus bertahan diantara framework pengembangan web lainnya. Dengan adanya prinsip-prinsip ini maka Ruby on Rails betul-betul mengurangi waktu dan usaha yang digunakan oleh pengembang dalam membangun aplikasi web yang kompleks.

2.1.2.1 Convention over Configuration (CoC)

Konsep ini merujuk kepada fakta bahwa Rails mengasumsikan sejumlah cara default yang harus dilakukan oleh seseorang ketika membangun aplikasi web sederhana. Ini berbeda dengan kebanyakan framework lain seperti framework web Struts (Java) dan Zope (PHP) yang membutuhkan proses konfigurasi yang panjang sebelum pengembang dapat memulai mengembangkan aplikasi paling sederhana sekalipun. Informasi konfigurasi ini biasanya disimpan dalam sebuah file XML, dan file dapat menjadi sangat besar dan akan menjadi sangat rumit untuk memeliharanya. Selain itu, pengembang mesti mengulangi seluruh proses konfigurasi setiap akan memulai proyek yang baru.


Sementara

itu,

Rails

dikembangkan

bertujuan

untuk

menghilangkan

konfigurasi yang berlebihan dan digantikan dengan adanya konvensi standar. Hasilnya, tidak dibutuhkan lagi file konfigurasi yang panjang. Jika pengembang mengikuti konvensi standar ini secara default, maka ia hanya perlu berhubungan dengan satu file konfigurasi yang singkat saja yang digunakan untuk membangun koneksi database.

Konvensi lain yang disediakan oleh Rails, diantaranya penamaan item-item yang berkaitan dengan database dan proses-proses yang melibatkan controller menemukan model dan view yang berkaitan.

2.1.2.2 Don’t Repeat Yourself (DRY)

Rails mendukung prinsip pemrograman DRY (Don’t Repeat Yourself). Ketika pengembang memutuskan untuk mengubah kelakuan dari aplikasi yang menggunakan prinsip DRY, maka ia tidak perlu untuk memodifikasi kode aplikasi pada lebih dari satu lokasi.

2.1.2.3 Pengembangan Agile

Banyak pendekatan tradisional dalam pengembangan perangkat lunak seperti iterative development dan waterfall model, biasanya mencoba untuk menguraikan secara detail dalam sebuah rencana statis yang panjang dengan menggunakan metoda prediktif utuk menentukan tujuan dan kebutuhan aplikasi.

Berlawanan

dengan

itu,

metode

pengembangan

agile

menggunakan

pendekatan adaptive. Suatu tim yang kecil (biasanya kurang dari 10 pengembang) secara iteratif menyelesaikan suatu unit kecil dari proyek. Sebelum memulai sebuah iterasi, tim mengevaluasi ulang prioritas untuk aplikasi yang sedang dibangun (prioritas-prioritas ini mungkin telah berubah ketika iterasi sebelumnya), sehingga tim mungkin perlu melakukan penyesuaian. Pengembang agile juga mengembangkan aplikasinya secara top-down, dimulai dari desain (yang mungkin saja sederhana berupa sketsa antarmuka pada selembar kertas).


Ketika sebuah aplikasi dibangun menggunakan metode agile, mungkin saja terjadi pembelokan kontrol disepanjang siklus pengembangan, dikarenakan upaya yang terus-menerus yang dilakukan tim untuk memperbaiki prioritas. Dengan menghabiskan waktu yang sedikit pada pembuatan spesifikasi fungsional dan jadwal long-running, pengembang yang menggunakan metodologi agile dapat sesegera mungkin memulai sebuah pengembangan aplikasi.

Berikut ini sedikit contoh yang mengilustrasikan bagaimana Rails mendukung praktik pengembangan agile: a. Pengembang dapat memulai bekerja pada layout dari aplikasi Rails sebelum membuat keputusan apapun terhadap penyimpanan data (walaupun keputusankeputusan ini mungkin berubah pada tahap selanjutnya) dan ia tidak perlu mengulangi mengerjai layout ini ketika memulai memasukkan fungsionalitas pada layar desain, segalanya berkembang secara dinamis seiring dengan persyaratannya.

b. Tidak seperti kode yang ditulis menggunakan C atau Java, aplikasi Rails tidak memerlukan sebuah langkah kompilasi supaya bisa menjadi executable. Kode Ruby diinterpretasikan secara on-the-fly, sehingga ia tidak membutuhkan bentuk kompilasi binari apapun untuk membuatnya executable. Perubahan kode di sepanjang pengembangan akan tetap memberikan pengembang feedback yang sesegera mungkin, yang dapat mempercepat laju pengembangan aplikasi secara signifikan.

2.1.3 Karakteristik Rails

Rails 2 mempunyai karakteristik yang berbeda dibandingkan web framework lainnya, diantaranya: 1. Berbasis arsitektur MVC (Model-View-Controller) Pemisahan data, presentasi dan logika kontrol dalam 3 tempat yang terpisah yang lebih memudahkan dalam memelihara kode yang sedang dibuat dan mengontrol perpindahan data.


a. Model Arsitektur model diatur oleh ActiveRecord yang merupakan salah satu lapisan dalam kode Rails yang menyediakan ORM (Object-Relational Mapping) antara Rails dan database. b. View Bagian view dari arsitektur menangani presentasi data, misalnya pada sebuah web browser. c. Controller Controller bersama-sama dengan view tergabung dalam ActionPack, bertugas mengambil masukkan pengguna dan merespon dengan meminta suatu operasi pada model dan mempersiapkan hasilnya untuk ditampilkan oleh bagian view.

Gambar 2.1 Arsitektur MVC pada Rails (Armstrong, 2008:6)


2. Rails secara default mengimplementasikan arsitektur REST. Mengenai REST ini akan dijelaskan pada BAB 2. 3. Rails merupakan sebuah framework yang full-stack.

Gambar 2.2 Kelengkapan Rails dengan Berbagai Pustaka (Benson, 2008:25) 4. Script Banyak script Rails tersedia yang memudahkan otomatisasi tugas-tugas pada siklus pengembangan yang dapat mengurangi beban kerja. 5. Validasi Rails memiliki metoda untuk memvalidasi apapun mulai dari pembuatan, penampilan, ukuran atau panjang sesuatu dan lain-lain. 6. AJAX Rails mendukung AJAX dimana sebuah browser dapat meng-update atau mengubah

sebagian

XMLHTTPRequest

dari sehingga

halaman

web

memungkinkan

yang update

merupakan

objek

dilakukan

tanpa

sepengetahuan dan persetujuan dari pengguna browser (backgrounding). 7. Migration Rails memiliki kemampuan untuk melakukan migrasi dari satu skema database ke yang lainnya dengan mudah hanya dengan melalui kode Ruby saja. 8. Console Rails mengijinkan pengembang untuk menguji aplikasi Rails secara black-box menggunakan perangkat irb dalam sebuah konsol.


9. Environment dan Pengujian Secara default, Rails menyediakan tiga environment paralel: development, test dan production. Demikian juga Rails menyediakan dukungan yang lengkap terhadap aktivitas pengujian. 10. Rake Perkakas pengembangan mirip make yang ditulis dalam bahasa Ruby yang berguna dalam menyelesaikan tugas-tugas yang berkaitan dengan proyek seperti pembuatan/penghapusan database maupun pengubahan skema database atau pemrosesan file-file dalam jumlah banyak.

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. Namanama 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 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 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: Viewing Order #124
Order #124

Items:

Office Chair, Medium

Ergonomic Keyboard

Tetapi, permintaan kepada resource yang sama dengan URI berbeda, orders/124.xml, dapat menghasilkan versi XML yang lebih machine-readable: Office Chair, Medium Ergonomic Keyboard

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 AcceptLanguage), 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.

Komponen

Tabel 2.2 Komponen pada Pemanggilan Web Service Disediakan Oleh Tujuan

Controller dan Action

Definisi route

Memilih sebuah kelas controller dan metode dalam kelas tersebut untuk dieksekusi sebagai respon terhadap web request

Format Respon

Header

HTTP

atau Menspesifikasikan format respon

definisi route (variabel dari action yang tersedia :format) Parameter Request

Form parameter

data

atau Memberikan parameter tambahan

yang

di- untuk memenuhi request dasar

encode pada URL Perintah HTTP

Request HTTP

Menyatakan

request

yang

diinginkan, apakah itu mengambil data,

memodifikasi

data

atau

menghapus 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


2.3.6 Dukungan Rails Terhadap Format Respon Berbeda

Ide bahwa satu resource dapat memiliki banyak representasi dalam tipe konten yang berbeda adalah salah satu prinsip dasar REST. Prinsip ini mengenali representasi yang berbeda dari suatu resource, apakah dalam format JavaScript, HTML, XML, ICS atau format apa saja, yang pada dasarnya.merupakan resource yang sama. Rails mendukung rendering respon yang berbeda berdasarkan pada tipe konten yang diinginkan klien, melalui metode respond_to.

Metode respond_to akan melakukan yield terhadap responder (instan dari ActionController::MimeRespons::Responder, yang biasanya dipanggil format),

yang dapat merespon terhadap bermacam-macam metode tipe konten agar dapat mengirim konten yang berbeda berdasarkan apa yang diharapkan klien (sebagaimana yang didefinisikan dalam request header Accept).

Metode responder yang umum digunakan adalah format.html dan format.xml, yang masing-masing mendefinisikan blok responder untuk request

HTML dan XML. Sebagaimana ini merupakan pemanggilan metode Ruby standar, maka ia dapat digabungkan dengan kode Ruby lain seperti kondisional. Blok dari method call yang pertama yang mencocokkan request header Accept akan dieksekusi. Blok ini biasanya merender response dalam format yang dispesifikasikan. respond_to do |format| format.html { render } format.xml { render :xml => @product } end

Route Rails yang default juga telah ditukar untuk mengakomodasi format yang berbeda. Dimana ketika sebelumnya route default /:controller/:action/:id, sekarang telah menjadi /:controller/:action/:id.:format. Ini melewatkan ekstensi file apa saja yang diberikan ke dalam controller yang bersesuaian sebagai params[:format]. Inilah yang dipergunakan oleh respond_to secara internal untuk

memutuskan response type.


Seperangkat MIME type yang dikenal Rails didefinisikan di dalam actionpack/lib/action_controller/mime_types.rb.

Setiap

pemetaan

memiliki

seperangkat MIME type, yang berupa symbol Rails yang digunakan untuk menunjukkan tipe-tipe tersebut (contohnya: :html atau :xml). Pada saat penulisan skripsi ini, tipe-tipe konten yang yang telah dikenal luas dapat digambarkan pada Tabel 2.4.

MIME type yang baru dapat didaftarkan dengan Mime::Type.register. Metode ini akan mengambil empat argumen: MIME type utama, shortcut Rails, seperangkat sinonim MIME type (seperti text/x-json untuk teks JSON), dan seperangkat sinonim ekstensi file, yang digunakan untuk membuat format ketika klien tidak mengirim header Accept atau mengirim yang salah.

Sebagai contoh, jika ingin menambahkan dukungan format JPEG ke dalam aplikasi. Ini dapat dilakukan dengan menulis format.jpg di dalam blok respond_to untuk merender response JPEG. Ini membutuhkan pemetaan format tipe jpg ke image/jpg, sebagaimana ekstensi jpg dan jpeg. Kita dapat melakukan ini dengan

memasukkan baris berikut ini pada config/initializers/mime_types.rb: Mime::Type.register "image/jpeg", :jpg, [], %w(jpeg)

Tabel 2.4 Daftar MIME Type yang Sudah Umum Digunakan Secara Luas Shortcut

MIME types

Text

text/plain

HTML

text/html, application/xhtml+xml

JS

text/javascript,

application/javascript,

application/x-javascript

CSS

text/css

CSV

text/csv

XML

application/xml, text/xml, application/x-xml

RSS

application/rss+xml

Atom

application/atom+xml

YAML

application/x-yaml, text/yaml

JSON

application/json, text/x-json


BAB 2 TINJUAUAN TEORITIS

Recommend Documents

Order #124