Apa SOAP dan apa REST
SOAP, mulanya didefinisikan sebagai Simple Object Access Protocol, adalah sebuah spesifikasi protokol untuk pertukaran pesan/informasi terstruktur dalam implementasi web servis di jaringan komputer. SOAP menggunakan Extensible Markup Language (XML) sebagai format pesannya, dan biasanya bergantung pada protokol layer aplikasi lainnya, terutama Hypertext Transfer Protocol (HTTP) dan Simple Mail Transfer Protocol (SMTP), untuk transmisi dan negosiasi pesan.
REpresentational State Transfer (REST) adalah sebuah arsitektur software untuk sistem terdistribusi semisal web. REST telah berkembang sebagai model desain web servis yang dominan saat ini. Istilah representational state transfer dikenalkan dan didefinisikan pada tahun 2000 oleh Roy Fielding dalam desertasi doktoralnya. Beliau merupakan salah satu penulis utama spesifikasi HTTP versi 1.0 dan 1.1. Sesuai konstrainnya, REST biasa disebut dengan “RESTful.”
REpresentational State Transfer (REST) adalah sebuah arsitektur software untuk sistem terdistribusi semisal web. REST telah berkembang sebagai model desain web servis yang dominan saat ini. Istilah representational state transfer dikenalkan dan didefinisikan pada tahun 2000 oleh Roy Fielding dalam desertasi doktoralnya. Beliau merupakan salah satu penulis utama spesifikasi HTTP versi 1.0 dan 1.1. Sesuai konstrainnya, REST biasa disebut dengan “RESTful.”
Arsitektur REST memiliki enam konstrain berikut untuk diterapkan:
- Client-server
- Stateless (tidak ada data client yang disimpan selama proses komunikasi)
- Dapat di-cache
- Sistem berlapis
- Code on demand (opsional)
- Interface yang seragam
Web servis RESTful (disebut juga web API RESTful) adalah sebuah web servis yang diimplementasikan menggunakan HTTP dan prinsip-prinsip REST. Web servis RESTful merupakan kumpulan resource yang
aspek-aspek sebagai berikut:
aspek-aspek sebagai berikut:
- URI untuk web servis, seperti http://example.com/resources/
- Tipe media internet yang didukung oleh web servis. Biasanya XML tetapi dapat juga berupa tipe lainnya asalkan valid sesuai standar HTTP
- Set operasi yang didukung oleh web servis dengan metode HTTP (misal: GET, PUT, POST, atau DELETE)
- API harus berbasis hypertext
Persamaan SOAP dan REST
Sebagai bentuk dari web service, SOAP dan REST memiliki kesamaan antara lain sebagai berikut:
- Digunakan sebagai metode pertukaran pesan dalam komunikasi dengan web servis
- Bisa menggunakan protokol web (HTTP, HTTPS)
Perbedaan SOAP dan REST
Adapun perbedaan yang terdapat pada SOAP dan REST dapat dijelaskan pada tabel berikut:
| Uraian | SOAP | REST |
|---|---|---|
| (1) | (2) | (3) |
| Protokol komunikasi | HTTP, HTTPS, SMTP, FTP | HTTP, HTTPS |
| Penggunaan bandwidth | Dalam jumlah request yang banyak, relatif boros bandwidth. Hal ini karena banyaknya markup dalam penulisan format XML | Relatif hemat bandwidth, karena markup-markup ekstra seperti pada XML tidak dipakai |
| Tren penggunaan | Banyak mulai beralih ke REST, meski masih tetap ada yang mempertahankan, misalnya untuk integrasi aplikasi ke sistem legasi pada sebuah perusahaan. | Mulai populer, banyak dipakai oleh penyedia web servis terkemuka, seperti twitter, yahoo!, flickr,bloglines, technorati, google, amazon, eBay, dsb |
| Aturan penulisan | Ketat, mengikuti spesifikasi XML (SOAP v1.2) | Tidak ada spesifikasi khusus |
| Format respon | XML dengan spesifikasi SOAP. Agak sulit bagi kita untuk membaca langsung dan memahaminya. | XML, JSON, atau format plain teks lainnya. Hal ini memudahkan penerima respon membaca dan memahaminya. |
| Attachment file | Bisa (karena dapat mengembalikan respon dalam format binary) | Tidak bisa |
| Sifat web servis pada umumnya | Tertutup, lebih ditujukan untuk vendor atau perusahaan tertent | Terbuka, bisa diakses siapa saja |
| Caching web | Relatif sulit | Mudah, karena menggunakan URI |
| Penggunaan standar | Standar lama (XML, HTTP) dan baru (SOAP) digunakan bersamaan | Standar yang sudah ada, seperti XML dan HTTP |
| Tool pengembangan | Banyak, baik komersial maupun opensource | Beberapa, karena tidak begitu dibutuhkan |
| Tool manajemen | Perlu, bahkan kadang harganya mahal | Menggunakan tool yang sudah ada pada sistem jaringan |
| Ekstensibel | Bisa, banyak ekstensi termasuk standar WS-* | Relatif tidak ekstensibel |
| Kemudahan implementasi | Mudah jika kita sudah memiliki lingkungan berbasis SOAP | Mudah |
Penjelasan Lain Soal Perbedaan antara SOAP dan REST sebagai Web Service
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
Posting Komentar