gedex’s blog

He.. sekarang saya akan membahas mengenai REST. Sebenarnya kalau dilihat ada beberapa tulisan saya di bagian sebelumnya yang perlu direvisi, misalnya: pada Bagian I, saya menulis “…tentang SOAP dan REST saya tulis nanti di webservices bagian 2…“. Dan ada lagi, di bagian II, saya menulis “kali ini saya akan membahas tentang SOAP dan REST“. Tapi kenyataannya, saya pisah postingan SOAP dan REST, atau bahkan nanti bisa saja ini berlanjut ke bagian IV, hehe.. Mau tahu alasannya:

1. Saya tidak suka 1 postingan itu terlihat begitu panjang. Posting yang panjang hanya membuat pembaca malas membaca secara keseluruhan. Karena menurut survey pada 1 orang (yaitu saya sendiri), tulisan yang panjang hanya akan dibaca paragraf awal dan akhir saja.
2. Saya malas merevisi jika itu bukan kesalahan typo dan grammar yang fatal, yang bisa menyebabkan salah pengartian (biasanya komentator yang peduli akan memberikan feedback). Kesalahan yang saya sebutkan di atas tidak tergolong kesalahan typo dan grammar yang fatal, dan lagi jika potongan post di baca secara terurut pasti pembaca akan tahu sebabnya.
3. Nah, inilah style menulis saya. Menulis A di paragraf awal dan memberi kesimpulan Z di akhir paragraf.

Pembahasan singkat REST sepertinya akan lebih banyak meninggalkan tanda tanya, karena ini lebih abstrak dibanding RPC-Style. Sebelumnya, saya akan membalik lagi ke postingan sebelumnya mengenai SOAP. Ada beberapa point yang tertinggal mengenai SOAP, yaitu mengenai arsitektur dasar Web Services (WS) yang meliputi pertukaran pesan / informasi, pendeskripsian WS dan publishing & discovering deskripsi WS. Ada 3 peranan dalam arsitektur WS ini, yaitu service requesters, service discovery agency dan service providers. Service provider mengimplementasikan web service dan mendefinisikan deskripsi servicenya ke requestor atau service discovery agency. Interaksi antara 3 pemeran WS ini meliputi 3 operasi, yaitu: publish, find dan bind. Pertama-tama requestor menggunakan operasi find untuk mendapatkan deskripsi service (bisa dari service discovery agency) dan menggunakan deskripsi itu mem-bind (memetakan) dirinya dengan service provider dan kini requestor dapat mengeksekusi (invoke) atau juga berinteraksi dengan service yang disediakan. Disini deskripsi service bisa berupa file WSDL (Web Services Definition Language) yang dipublish oleh service providers yang menjelaskan bagaimana requestor menggunakan pesan SOAP yang benar agar dapat berinteraksi dengan WS providers. Nah muncul lagi deh teknologi WSDL yang mungkin masih jadi tanda tanya bagi Anda. Penjelasan lebih lanjut mengenai arsitektur WS dan bagaimana teknologi SOAP, WSDL, HTTP berperan di dalamnya bisa Anda baca di W3C Working Draft mengenai Web Services Architecture.

Sebelum membahas REST, saya akan menggambarkan situasi dimana ada anonymous yang sedang mendengarkan penjelasan saya dan terjadi perbincangan *hayah gaya. Perlu diingat saya bukan pakar RESTmatika, dan hanya membaca referensi yang ada di bawah dan menuangkannya kembali. Kembali ke REST (Representational State Transfer). Terminologi REST dikemukakan oleh Roy Fielding (salah satu penulis spesifikasi HTTP) dalam disertasi Ph.D. nya untuk menggambarkan sebuah style arsitektur dari sistem network. Ada dua pengartian REST, pertama: REST merupakan collection (saya menggunakan kata tetap collection, bukan koleksi, karena AtomPub menggunakan element <collection> untuk mendeskripsikan koleksi service) dari prinsip-prinsip arsitektur network yang menggambarkan bagaimana resource didefinisikan dan dialamati (bagaimana mengakses resource yang didefinisikan). Pengertian kedua: Sebuah interface yang mengirim data (pada domain tertentu) melalui HTTP tanpa menggunakan layer messaging seperti SOAP atau session tracking via HTTP cookies. Kedua pengertian ini dapat saling bertentangan dan saling menimpa. Kita dapat saja mendesain sistem perangkat lunak besar yang sesuai dengan style arsitektur REST tanpa perlu menggunakan HTTP dan tanpa perlu berinteraksi dengan WWW. Kita juga dapat mendesain interface berbasis XML+HTTP yang tidak sesuai dengan prinsip REST, tapi meniru RPC-style. Inilah yang yang membuat bingung, bagaimana sih terminologi REST harus digunakan? Dan sistem seperti apa sih yang sesuai dengan prinsip REST? Sistem yang mengikuti (mengimplementasi) sesuai dengan prinsip REST nya si Roy Fielding ini sering disebut sebagai RESTful. AtomPub (Atom Publishing Protocol) yang digunakan untuk posting blog sering dianggap sebagai standard RESTful protocol (saya akan bahas AtomPub juga, nanti). OK, sampai saat ini pasti konsep RESTful masih belum jelas bagi Anda, kita kembali lagi ke REST. Kenapa si Roy Fielding menyebut style arsitektur miliknya ini sebagai “Representational State Transfer” ? Hmmm.. Ada tiga kata yang perlu di jelaskan disini, yaitu “Representation” (saya akan selalu menggunakan kata representation, tapi tetap berarti suatu representasi, wujud atau bentuk), “State” dan “Transfer“. OK, kita anggap web terdiri atas kumpulan resources. Domain-domain di internet ini memberikan resources baik kepada browser atau aplikasi yang diprogram untuk mengakses resource tersebut. Sebuah resource merupakan sesuatu (dokumen, file atau apapun) yang dinginkan oleh pengakses (client). Browser menginginkan resource tersebut disajikan dalam dokumen HTML, aplikasi lain mengingikan dalam format XML agar bisa diolah lebih lanjut. Misal universitas Gunadarma memberikan resource informasi mahasiswa dengan NPM (Nomor Pokok Mahasiswa) 20102246. Client dapat mengakses resource tersebut melalui URL:

http://www.gunadarma.ac.id/mahasiswa/20102246

Client (browser) mengaksesnya (HTTP GET request) dan sebuah representation dari resource tersebut diberikan (misal 20102246.html, karena browser merequest dokumen html). Representation menempatkan aplikasi client (browser) dalam sebuah state. Client menjelajahi resource dan menemukan hyperlink di dalam dokumen 20102246.html, jika hyperlink tersebut diakses maka resource lainnya diakses. Representation baru dari resource tersebut menempatkan aplikasi client ke state lain lagi. Dengan itu, aplikasi client mengubah (transfer) state di setiap representation dari resource. Banyak diskusi menyebutkan ada dua jenis state, yaitu: 1) application state dan 2) resource / client state. Application state adalah suatu state yang tidak mempengaruhi resource di server, itu hanya representasi resource yang lain di mata client (dimana server tidak peduli akan hal itu). Sedangkan resource state adalah state yang mempengaruhi suatu resource (terjadi aksi / operasi resource di server), hal ini seringkali dikaitkan dengan operasi UPDATE. Jadi menjelajah hyperlink dari representasi resource belum tentu berpindah resource state, bisa saja hanya application state. Nah itu lah Representational State Transfer! Berikut penjelasan Roy Fielding mengenai Representational State Transfer :

Representational State Transfer is intended to evoke an image of how a well-designed Web Application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.

REST bukanlah standard seperti SOAP. Tidak ada spesifikasi REST di W3C. Anda juga tidak akan mendapatkan IBM, Microsoft ataupun Sun menjual REST toolkit untuk developer. Kenapa? Karena REST adalah style arsitektural. Kita tidak dapat mengkemas style tersebut. Kita hanya dapat memahaminya lalu mendesain Web Services kita sesuai prinsip style tersebut (Analoginya adalah arsitektur client-server. Tidak ada standard untuk client-server, yang ada hanya karakteristik dan prinsip yang perlu dipegang untuk mengimplementasi style arsitektural). Sebelumnya telah saya singgung, bahwa AtomPub sering dianggap sebagai standard RESTful protokol. Nah inilah salah satu standard yang sering digunakan untuk mengimplementasi arsitektur REST (selanjutnya disebut RESTful). Spesifikasi untuk AtomPub juga telah di definisikan oleh IETF dalam RFC5023. Saat googling pun saya menemukan beberapa library untuk membantu mempermudah implementasi Web Services dengan protokol AtomPub. Nah semakin jelas kan perbedaan style arsitektural dan pengimplementasi style-nya!

Saya yakin gambaran REST masih buram jika Anda baru mendapatkan definisi REST di blog ini. Mari kita lanjut ke contoh RESTful yang lebih spesifik, yaitu World Wide Web (WWW). OK, WWW merupakan kunci dari contoh desain RESTful. Web terdiri dari HTTP (Hypertext Transfer Protocol), jenis konten (meliputi HTML, XML, image, dsb) dan teknologi internet lainnya seperti Domain Name System (DNS). HTTP memiliki sebuah interface yang seragam untuk mengakses resources, yang terdiri dari URI (Uniform Resource identifier. Dalam web kita lebih mengenal URL dan disini istilah URI dan URL dapat saling menggantikan), methods (POST, GET, PUT, HEAD, DELETE, dsb.), status codes (200 untuk response OK, masih ingat posting bagian I mengenai XML-RPC? Lihat RFC2616), headers dan content (bisa format HTML, XML ataupun binary untuk image. MIME type). Methods yang cukup penting dalam HTTP adalah POST, GET, PUT dan DELETE. Methods ini sering dianalogikan sebagai operasi CREATE, READ, UPDATE dan DELETE (CRUD) dalam teknologi database. Tapi dalam HTTP operasi POST bisa meliputi Create, Update dan Delete. Operasi GET sebagai READ, operasi PUT bisa meliputi CREATE dan UPDATE, dan operasi DELETE sebagai DELETE. Apa hubungannya semua teknologi HTTP, URL, resource representation dan MIME type dengan arsitektur REST? OK, Kita ambil contoh Toko Buku Online. Misalkan developer Toko Buku Online telah mendeploy beberapa Web Services yang memberikan layanan ke pelanggan untuk:

• Mendapatkan daftar buku
• Mendapatkan informasi buku tertentu
• Mengirim PO (Purchase Order)

Kita akan membuat layanan ini bergaya RESTful. Pertama: Mendapatkan daftar buku. Web services yang dibuat diakses melalui URL untuk mendapatkan resource “daftar buku”. Misal, client menggunakan URL di bawah ini untuk mendapatkan daftar buku:

http://www.tokobuku-gedex.com/books/

Perlu dicatat, bahwa “bagaimana” web services menghasilkan daftar buku kepada client itu sepenuhnya transparan. Semua client mengetahui bahwa jika dia mengakses URL di atas maka dokumen yang berisi daftar buku akan diberikan. Karena implementasinya transparan ke client, maka tokobuku-gedex.com dapat mengubah implementasi dasar dari resource ini tanpa mempengaruhi client. Ini disebut loose coupling. Dokumen yang di terima client dari URL di atas adalah:

<?xml version="1.0">
<gedex:Books xmlns:gedex="http://www.tokobuku-gedex.com" xmlns:xlink="http://www.w3.org/1999/xlink">
    <Book id="0101" xlink:href="http://www.tokobuku-gedex.com/books/0101" />
    <Book id="0102" xlink:href="http://www.tokobuku-gedex.com/books/0102" />
    <Book id="0103" xlink:href="http://www.tokobuku-gedex.com/books/0103" />
    <Book id="0104" xlink:href="http://www.tokobuku-gedex.com/books/0104" />
</gedex:Books>

Dengan mengasumsikan bahwa melalui negoisasi content (pada saat request dengan operasi GET, client mencantumkan header Content-Type: text/xml. Dengan ini server memberikan response dalam format XML), service dari tokobuku-gedex mengetahui bahwa client menginginkan representation dalam format XML. Dapat dilihat bahwa dokumen daftar buku berisi link untuk mendapatkan detail informasi setiap buku. Inilah kunci dari REST. Client berpindah (transfer) dari satu state ke state berikutnya dengan memahami dan memilih di antara alternatif URL di dokumen yang di response server. OK, sedikit jelas kan? Layanan selanjutnya adalah mendapatkan mendapatkan informasi buku tertentu. Misal, client merequest buku 0101:

http://www.tokobuku-gedex.com/books/0101

Server merespon dengan memberikan dokumen:

<?xml version="1.0">
<gedex:Book xmlns:gedex="http://www.tokobuku-gedex.com" xmlns:xlink="http://www.w3.org/1999/xlink">
    <Book-ID>0101</Book-ID>
    <Judul>Web Services untuk Pemula</Judul>
    <Summary>Buku ini cocok untuk pemula yang ingin mengenal Web Services</Summary>
    <Penulis>Gedex Paganini</Penulis>
    <SampleChapter xlink:href="http://www.tokobuku-gedex.com/books/0101/sample" />
    <HargaSatuan matauang="IRD">50000</HargaSatuan>
    <Jumlah>8</Jumlah>
</gedex:Book>

Perhatikan bagaimana data di atas memiliki link ke data lainnya (sample chapter dari buku tersebut). Setiap dokumen response memberikan keleluasaan bagi client untuk terus mendapatkan informasi tambahan. Bahkan mungkin dokumen sample chapter juga akan memberikan link, misal chapter 1 dan chapter 2 yang berarti ada dua chapter yang disediakan bebas. Oia, satu layanan lagi adalah mengirim PO (Purchase Order). Developer tokobuku-gedex menyediakan URL untuk mengirim PO. Client membuat PO dokumen sesuai dengan skema PO yang sudah didesain sebelumnya (dan di publish oleh tokobuku-gedex melalui file WSDL). Client lalu mengirim PO.xml sebagai payload dari HTTP POST. Layanan PO merespon terhadap datangnya HTTP POST, cek URL-nya dan memproses PO.xml. Disinilah operasi Create, Update atau Delete terjadi di sisi server. Client dapat mendapatkan dokumen PO setelah operasi Create (pertama kali mengirim PO dengan POST), mengedit (PUT -> Update) dan menghapus (DELETE) nya kemudian. Kini PO itu menjadi bagian informasi yang di share antara client dan server. Informasi ini (PO) diberikan oleh server melalui URL dan diekspos sebagai Web Service. Masih bingung sejauh ini? Bagaimana kita dapat menentukan Web Services itu RESTful? OK, RESTful Web Services memiliki karakteristik sebagai berikut:

• Client-Server: Interaksi bergaya pengambilan: mengkonsumsi komponen berarti mengambil representation.
• Stateless: Setiap request dari client ke server harus mengandung semua informasi yang diperlukan server untuk memahami maksud dari request, dan request tidak dapat memanfaatkan server untuk mengingat / menyimpan konteks apapun.
• Cache: Untuk meningkatkan efisiensi jaringan, respon harus dapat melabeli data sebagai cache atau non-cache.
• Uniform interface: Semua resource diakses dengan interface generik (HTTP GET, POST, PUT, DELETE).
• Resource yang memiliki nama: Sistem terdiri atas resource yang mempunyai nama berdasarkan URL-nya.
• Representation resource yang saling terkoneksi: Representasi dari resource saling terhubung menggunakan URL, oleh karenanya client dapat untuk berpindah dari satu state ke state lainnya.
• Komponen berlayer: Perantara seperti proxy server, cache server, gateway, dsb, dapat dimasukkan sebagai komponen antara client dan resource untuk mendukung performa, keamanan, dll.

Selain karakteristiknya, ada beberapa prinsip yang perlu dipegang agar sebuah desain Web Service itu RESTful, yaitu:

1. Kunci untuk membuat Web Services dalam sebuah jaringan REST (seperti Web) adalah mengidentifikasi semua bentuk konsep yang ingin kita ekspos sebagai service. Pada contoh di atas, kita lihat beberapa contoh resource: daftar buku, informasi detail buku tertentu, purchase order.
2. Membuat sebuah URL untuk setiap resource. Resource harus berbentuk noun (kata benda), bukan verb (kata kerja). Nah inilah yang membedakan antara REST dan RPC-style (akan saya jelaskan di bawah). Sebagai contoh:Untuk mendapatkan resource buku tertentu jangan gunakan URL seperti :

   http://www.tokobuku-gedex.com/books/getBook?id=0101

   Perhatikan adanya verb (getBook) pada URL di atas. Gunakanlah noun, seperti:

   htttp://www.tokobuku-gedex.com/books/0101

3. Mengkategorikan resource menurut permission untuk client, apakah membaca saja, atau dapat mengedit dan menghapus. Maksudnya apakah client hanya dapat mendapatkan representation dari resource, atau bisa memodifikasi resource. Untuk mendapatkan representation resource, client menggunakan operasi HTTP GET. Untuk membuat suatu resource client menggunakan operasi HTTP POST, HTTP PUT untuk mengedit suatu resource dan HTTP DELETE untuk menghapus resource.
4. Semua resource yang dapat diakses melalui HTTP GET tidak mempunyai efek terhadap resource. Resource hanya memberikan representasi resource, tidak ada modifikasi terhadap resource itu sendiri.
5. Tidak ada representation yang berisi semua informasi dan tidak terhubung dengan resource lainnya. Gunakan hyperlink dalam setiap representasi resource agar client dapat memperoleh informasi lebih detail atau informasi lainnya yang berkaitan.
6. Sistem didesain untuk memberikan data secara bertahap. Jangan berikan semuanya dalam sebuah dokumen respon. Tapi sediakan hyperlink untuk memperoleh detail lebih lanjut.
7. Beri penjelasan terhadap format dari data respon menggunakan skema (DTD, W3C schema, RelaxNG atau Schematron). Untuk service yang membutuhkan POST atau PUT untuk membuat atau mengedit resource, sediakan skema untuk memberi penjelasan format respon.
8. Beri penjelasan bagaimana services kita harus dieksekusi dengan menggunakan file WSDL atau bisa dengan dokumen HTML sederhana.

Anonymous: “Hmm.. kisanak saya sedikit mulai ada gambaran mengenai REST, tapi ngapain kisanak sebelumnya menceritakan XML-RPC dan SOAP, ya RPC-style gitu deh”.

Me: “OK, good question! Perhatikan prinsip RESTful no.2 di atas! Antara noun dan verb! Sebenarnya saya menemukan banyak referensi yang berisi RPC VS REST. Dan akan saya tulis kembali disini untuk memperjelas keduanya”.

Sebenarnya perbedaan Web Services yang RESTful dan RPC-style cukup jelas, yaitu:

1. REST mendefinisikan “resources”. Akses didefinisikan sebagai: bagaimana mendapatkan resource (representation), menyimpan / membuat resource (HTTP POST), memodifikasi (HTTP PUT) dan menghapus resource (HTTP DELETE). RPC-style mendefinisikan “methods“. Akses didefinisikan sebagai: bagaimana mengeksekusi methods di server dengan menggunakan standard tertentu (XML-RPC atau SOAP) sebagai layer messaging.
2. REST memiliki noun berupa resources. RPC-style memiliki verb berupa methods. Dalam desain RESTful terdapat aturan yang mengikat aspek resources, yaitu interface (verbs dan jenis konten) resources. Dalam RESTful, verbs terikat pada metode request HTTP (GET, POST, PUT, DELETE). Jenis konten merupakan representasi dari resource (HTML, XML, file, dll). Aplikasi berbasis RPC-style menyediakan objek-objek dimana setiap objek memiliki method yang dapat dieksekusi (invoke). Untuk dapat berkomunikasi dengan aplikasi RPC-style, client harus mengetahui terlebih dahulu objek-objek yang tersedia, methods yang tersedia untuk mengakses objek dan tipe objek. RESTful didesain untuk mendefinisikan kumpulan resource dimana client dapat berinteraksi dengan cara yang sama, dan juga menyediakan hyperlink antara resource dimana client dapat menjelajahi tanpa perlu mengetahui terlebih dahulu kumpulan resource. Misal:Tokobuku-gedex membuat Web Services dengan RPC-style. Developernya menggunakan XML-RPC sebagai layer messaging, yang bisa diakses melalui URL http://www.tokobuku-gedex.com/xml-rpc/. Methods yang disediakan adalah:

   getBook()
   addBook()
   updateBook()
   removeBook()
   listBooks()
   findBook()
   getPenulis()
   addPenulis()
   updatePenulis()
   removePenulis()
   listPenulis()
   findPenulis()

   Developer kemudian mendokumentasikan methods, parameter serta tipe data yang digunakan. Untuk mengakses aplikasi ini, client dapat menulis code (misal dengan IXR library) yang mungkin seperti ini:

   $client = new IXR_Client('http://tokobuku-gedex.com/xml-rpc/');
   if ( !$client->query('gedex.getBook', 0101) ) {
       die($client->getErrorMessage());
   } else {
       $result = $client->getResponse();
   }

   Dengan REST, sistem ditekankan pada koleksi resources, atau nouns; misal dengan REST resource tokobuku-gedex didefinisikan menjadi:

   http://www.tokobuku-gedex.com/books
   http://www.tokobuku-gedex.com/books/{book} (id buku untuk setiap buku)
   http://www.tokobuku-gedex.com/penulis
   http://www.tokobuku-gedex.com/penulis/{nama_penulis}

   Nah seperti telah dijelaskan di atas, bahwa setiap resource memiliki identitas noun-nya. Client dapat memulai sebuah resource dari sebuah kumpulan buku, dan kemudian berpindah ke spesifik buku tertentu, lalu kemudian melihat sample chapter yang disediakan. Client mendapatkan resource dengan standard HTTP REQUEST GET untuk mengunduh (copy) representasi resource, PUT untuk mengedit (paste) resource aslinya atau DELETE untuk menghapus resource. POST umumnya digunakan untuk operasi pembuatan atau penambahan data ke kumpulan data. Perhatikan bagaimana setiap objek (sebuah resource) memiliki URL tersendiri dan dapat dengan mudah di cache, di kopi dan dibookmark.

Anonymous: “Saya melihat ada sedikit kekurangan dengan penjelasan kisanak. Mmhh, jika resource didefinisikan dengan URL dan diekspos ke publik seperti itu, bagaimana mengamankan resource tertentu yang mana hanya client tertentu saja yang boleh mengakses atau mengeditnya? Sori jika saya banyak nanya sama kisanak!”

Me: “No problemo anonymous! Saya suka pertanyaan Anda!”

Dalam spesifikasi HTTP (cek RFC1945, RFC2616, RFC2617), dijelaskan bahwa dalam transaksi HTTP ada sebuah metode untuk authentifikasi akses (atau disebut basic access authentication) yang mana client dapat menyediakan credential (username dan password) saat membuat request. Sebelum mengirim request, username dan password di encode dengan base-64. Contoh, jika username=gedex dan password=asdf maka akan digabungkan menjadi gedex:asdf dan jika di encode ke base-64 menjadi Z2VkZXg6YXNkZg==. Ini memang tidak meningkatkan sisi keamanan, tapi agar tidak terbaca jelas saja oleh orang lain. Jika ingin meningkatkan keamanan koneksi HTTP, ada metode yang tersedia, yaitu: HTTPS skema dan HTTP 1.1 Upgrade header (baca RFC2817). Contoh basic access authentication:

• Client merequest sebuah resource yang membutuhkan authentifikasi, tapi client tidak menyertakan username dan password. Umumnya ini karena client langsung mengakses alamat atau mengikuti link dari sebuah resource. Berikut cara client request tanpa menyertakan credential:

  GET /books/underground HTTP/1.0
  Host: tokobuku-gedex.com

• The server merespon dengan respon code 401 dan menyediakan authentication realm.

  HTTP/1.0 401 UNAUTHORIZED
  Server: Apache/2.2.8 (Win32) DAV/2 mod_ssl/2.2.8 OpenSSL/0.9.8g mod_autoindex_color PHP/5.2.5
  WWW-Authenticate: Basic realm="Toko Buku Gedex Site"
  Content-Type: text/html
  Content-Length: 311
  Date: Mon, 21 Apr 2008 06:02:12 GMT
  
  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
  <HTML>
    <HEAD>
      <TITLE>Error</TITLE>
      <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
    </HEAD>
  <BODY><H1>401 Unauthorised.</H1></BODY>
  </HTML>

• Pada saat itu client akan menghadapi authentication realm (umumnya sebuah informasi dari sistem yang sedang diakses) dan akan meminta username dan password. User dapat meng-cancel proses authentifikasi.
• Jika client memberikan username dan password, request dikirim kembali dengan menyertakan authentication header.

  GET /books/underground HTTP/1.0
  Host: tokobuku-gedex.com
  Authorization: Basic Z2VkZXg6YXNkZg==

• Jika server menerima authentifikasi maka halaman yang direquest akan diberikan (umumnya status code 200 akan diberikan), tapi jika username atau password salah, server dapat memberikan status code 401 dan menyediakan authentifikasi realm lagi.

  HTTP/1.0 200 OK
  Server: Apache/2.2.8 (Win32) DAV/2 mod_ssl/2.2.8 OpenSSL/0.9.8g mod_autoindex_color PHP/5.2.5
  Date: Mon, 21 Apr 2008 06:02:12 GMT
  Content-Type: text/html
  Content-Length: 10512

Well, masih banyak pembahasan mengenai RESTful yang belum bisa saya muat di sini. Ada suatu bahasan mengenai Web Services yang secara tidak sengaja RESTful, seperti apa yang Mark Baker tulis. OK, sampai disini pembahasan mengenai REST. Mengenai AtomPub akan saya bahas pada postingan berikutnya.

Referensi

• W3C Workig Draft - Web Services Architecture
• Representational State Transfer di Wikipedia
• REST for the Rest of Us
• Building Web Services the REST Way
• A Brief Introduction to REST
• The Atom Publishing Protocol
• A RESTful Web service, an example
• RESTify DayTrader
• Accidentally RESTful