SOAP Overview
Mengacu pada arsitektur RPC (remote procedural call) atau RMI (remote method invocation). Client mengakses sebuah method (umumnya dinyatakan melalui sebuah interface), yang merupakan representasi dari method (operasi) yang terdapat di server [1].
Arsitektur ini menyembunyikan mekanisme network messaging antara client dan server, maka logikanya, di suatu tempat di dalam arsitektur RPC, pasti terdapat proses 'binding' yang menunjukkan lokasi server dan method apa saja yang disupport oleh server tersebut.
Mengenai object yang dipertukarkan (melalui arguments atau result), terjadi peng-copy-an object antara client dan server [2]. Misalnya client menggunakan instance object A, dengan field f1, f2, f3 sebagai argument pada remote method, server pun harus memiliki instance sebuah object, kita sebut saja AA dengan field ff1, ff2, ff3 (yang masing2 adalah representasi dari f1, f2, f3 dari object A).
Untuk menangani pertukaran object tadi, dibutuhkan semacem 'parser' yang mengambil value2 dari object A, dikemas dalam suatu format tertentu (marshalling), dan dikirim ke server. Di sisi lain, server menerima message dalam format tertentu, yang harus di-parse value2nya ke dalam object AA (unmarshalling). Client mengenal object Stub sedangkan server menggunakan object Skeleton untuk kebutuhan tadi.
Secara umum urutan prosesnya: client <-> stub <-> network <-> skeleton <-> server.
Class-class yang melakukan proses-proses tersebut 'dibundle' sebagai sebuah proxy, dihandle oleh library. Yang langsung diakses oleh class client adalah interface yang memiliki remote method.
Sebagaimana sebuah operasi/method dalam object oriented programming, ada mekanisme exception handling. Secara otomatis, exception yang terjadi di sisi server akan di-throw melalui element fault pada soap message. Element ini akan berisi nama class dan deskripsi exception [3]. Dengan kata lain, informasi yang spesifik mengenai exception di server akan dibawa ke client.
Selain itu jika client menerapkan exception handling terkait aktivitas tersebut, perlu diperhatikan juga bagaimana jika client dan server menggunakan bahasa yang berbeda (misalnya clientnya php, sedangkan servernya java, atau sebaliknya).
Semua spesifikasi teknis mengenai implementasi soap, seperti object-object yang digunakan (dalam argument dan resultnya), method atau operasi yang disupport, alamat endpoint, didefinisikan dalam WSDL [4]. Baik server maupun client, menggunakan acuan WSDL yang sama dan untuk menyesuaikan, beberapa IDE telah menyediakan fitur untuk meng-generate classes-to-wsdl (bottom-top) atau wsdl-to-classes (top-bottom) sehingga development untuk implementasinya jauh lebih mudah.
Contoh soap message: http://wiki.developerforce.com/page/Sample_SOAP_Messages_%2810.0_API%29.
REST Overview
Arsitektur ini mengacu pada network messaging melalui HTTP. Berbeda sudut pandang dengan SOAP, REST menggunakan sudut pandang representasi resource (data). Tiap resource dinyatakan dalam URI yang unique [5].
Saat client mengakses URI tertentu, bisa dibayangkan yang diakses oleh client itu adalah data. Aktivitas yang bisa dilakukan client terhadap data-data tersebut mengacu pada method yang dimiliki oleh protocol HTTP: GET (mengambil data), POST (input data), PUT (update data), DELETE (hapus data) [6].
Misalnya client mengirimkan HTTP method GET ke uri http://domain.com:8080/application/user/usercode, dan yang akan kita dapatkan sebagai response adalah detail informasi user yang codenya 'usercode'. Atau contoh lain, misalnya client mengirimkan HTTP method POST ke URI http://domain.com:8080/application/user untuk menginput user baru, dan response yang di dapat misalnya adalah informasi status input sukses/gagal, dll.
Berfokus pada representasi data memungkinkan kemudahan untuk melakukan streaming dalam berbagai bentuk tipe data (atau mime). Umumnya data yang dipertukarkan berupa json atau XML, bahkan plain text. Tidak menutup kemungkinan tipe mime lainnya, bergantung pada apa yang disupport oleh sang server.
Itu dari sisi clientnya.
Dari sisi servernya, untuk memungkinkan semua itu terjadi, server harus memliki method-method untuk menerima tiap HTTP method tadi, kemudian menerjemahkan URI yang diakses dan mesage yang dikirimkan untuk kemudian dipilah-pilah berdasarkan tiap informasi tadi fungsi/method/operasi apa yang harus dijalankan agar client mendapatkan result data yang diinginkan.
Dalam implementasinya, berbeda dengan SOAP yang parsingnya telah disediakan oleh library (baik client-side mau pun server-side) dan formatnya telah ditentukan dalam WSDL, arsitektur REST memberikan kesempatan kepada developer untuk membuat parsernya sendiri (baik client-side maupun server-side).
secara umum urutan prosesnya: client <-> parser <-> connector <-> network <-> connector <-> parser <-> server.
Karena tidak ada acuan teknis spesifik seperti WSDL, maka idealnya server harus menyediakan dokumen tambahan berupa spesifikasi format message (atau mime), alamat resource (URI), field-field yang dibutuhkan (saat request dan saat response), dan client harus menyesuaikan.
Mengenai exception, idealnya REST akan menggunakan HTTP response status [7] sebagai acuan (melalui status line [8]). Server melakukan mapping antara exception yang terjadi dengan HTTP response status. umumnya library REST menyediakan fasilitas untuk ini. Tapi tidak menutup kemungkinan untuk mengirimkan exception stacktrace atau status code melalui body message.
SOAP and REST Comparison
1. Message Format
SOAP menggunakan XML dengan content yang relatif besar jika dibandingkan dengan REST yang menggunakan XML. Pada REST, message yang dikirimkan hanya datanya saja, sedangkan SOAP mengirimkan hal-hal lain seperti yang termuat dalam envelopenya [11]. Jika kita bandingkan mengirimkan data yang sama, maka byte yang di-stream oleh SOAP pasti akan lebih besar dari REST.
Selain itu REST lebih fleksibel untuk mengubah format message, sebagai contoh misalnya ditemukan bahwa XML parsing membutuhkan effort lebih besar, maka message format bisa menggunakan json atau text plain.
2. Scalability
Pada SOAP, class Stub/Skeleton melakukan beberapa fungsi, seperti parsing dan open connection. keduanya dihandle oleh SOAP library. Kita tidak dapat mengukur effort masing-masing, misalnya berapa total size yang dibutuhkan hanya untuk parsing saja, atau untuk connectionnya saja.
REST lebih baik karena komponen-komponennya terpisah, seperti parser terpisah dengan open connection. Dengan arsitektur demikian, kita bisa mengukur effort (size atau duration) masing-masing komponen dengan spesifik, dan hal ini akan sangat memudahkan untuk melakukan tuning.
3. Conversation State (stateful/stateless)
Conversation dikatakan stateless jika server tidak menyimpan informasi tertentu mengenai request yang dilakukan oleh client, selain itu server tidak menyimpan session tertentu. Kasarnya, stateless conversation adalah 'cuma messaging saja'. Stateful adalah kondisi sebaliknya. Protocol HTTP secara 'alamiah' bersifat stateless, sehingga REST maupun SOAP dapat menerapkan stateless conversation.
Tambahan pada SOAP, selain stateless, dia juga men-support stateful conversation, misalnya melalui fitur WS-AtomicTransaction [9]. Untuk REST, hal demikian bisa dilakukan dengan tambahan coding server-side. Jika hal demikian dikatakan bukan REST, mari kita sebut saja dia bernama 'CustomizedREST' :D, yang pasti arsitektur demikian bisa dilakukan [10].
Mana yang lebih baik digunakan untuk kasus stateful? Menurut saya, disesuaikan dengan kebutuhan dan resource yang mengerjakan. SOAP bisa meminimalisir effort development (coding), tetapi kita tidak punya kontrol pada kinerja processingnya. REST lebih besar effort developmentnya, tetapi kontrol tetap milik developer.
4. Security
SOAP memiliki fitur security, bisa dilihat di http://msdn.microsoft.com/en-us/library/ms951273.aspx. Sedangkan REST bisa menggunakan SSL, tetapi berdasarkan sebuah diskusi di forum, SSL untuk REST bisa menimbulkan masalah saat load balancing [12]. Best practicenya adalah menggunakan TLS, dan otorisasi menggunakan OAuth [13], menurut referensi [13] itu pun tidak dianjurkan menggunakan SSL.
References
Note
Review mengenai materi ini bersifat discussable, bisa terlihat maraknya pembahasan mengenai topik ini di mesin pencari dengan keyword, misalnya: rest vs soap.
Jika ada tambahan atau sanggahan atau ingin berdiskusi, silakan disampaikan melalui comment.
