PERBEDAAN WEB SERVICE SOAP DAN REST
Web service
merupakan kunci integrasi untuk aplikasi-aplikasi yang berbeda platform,
bahasa, dan sistem. Dengan kata lain kita dapat menyebut web service sebagai
"titik temu bisnis".
REST masih cukup
baru, sedangkan SOAP telah merevolusi RPC dan lebih terbuka dibanding
batasan-batasan yang ada di versi sebelumnya.
Terminologi
·
SOAP adalah Simple Object Access Protocol
·
HTTP berbasis API berarti API yang diekspos
sebagai salah satu atau lebih HTTP URI dan respon berupa XML/JSON. Skema respon
dapat dikustomasi untuk setiap objek
·
REST pada sisi yang lain menambahkan sebuah
elemen untuk menggunakan URI standar, dan juga memberikan kepentingan kepada
penggunaan HTTP (seperti GET/POST/PUT, dsb.)
Meskipun
beberapa tahun ini kita melihat perkembangan teknologi web service, tetapi
popularitas SOAP tetap tidak berkurang. Arsitektur internet datag dengan argumen yang bagus untuk menekan soap di sisi yang lain: ada metode
yang lebih baik untuk membangun web service dalam bentuk Representational State
Transfer (REST).
REST lebih
kepada filosofi lama, ketimbang sebuah teknologi yang baru. Tetapi dalam
kenyataannya datang kemudian dalam teknologi. Sedangkan SOAP nampak seperti
lompatan baru ke fase selanjutnya dalam pengembangan internet dengan sekumpulan
spesifikasi baru, filosofi REST mendukung bahwa prinsip dan protokol yang sudah
ada di Web cukup untuk membuat web servide yang kuat (robust). Hal ini berarti
bahwa developer yang mengerti HTTP dan XML dapat mulai membangun web service
tanpa membutuhkan toolkit di belakang apa yang biasanya digunakan dalam
pengembangan aplikasi internet.
Dalam arsitektur
REST, kunci resource diidentifikasi, dapat berupa entitas, koleksi, atau yang
lain dimana nampak lebih bernilai ketika memiliki URI sendiri. Metode standar _
dalam kasus ini, cara kerja HTP, dipetakanke semantik-semantik
resource-specific. Semua resource mengimplamentasikan interface yang seragam.
Dimensi tipe konten, yang mengijinkan representasi berbeda dari
resource-resource ( dalam XML, HTML, dan plain text), sebaik kemampuan links ke
resource dalam representasi resource. Pikirkan, misal GET pda /customer/4711
akan mengembalikan dokumen yang mengandung link secara spesifik /order/xyz.
Saat ini dapat
kita lihat sendiri bahwa banyak web service baru yang dkembangkan menggunakan
arsitektur REST dibandingkan dengan SOAP. Mari kita lihat sekilas dan pahami
poin-poin dasar apa itu REST.
REST web service
REST pada
dasarnya setiap URL unik adalah representasi dari beberapa objek. Kita dapat
memperoleh konten-konten objek tersebut menggunakan HTTP GET, untuk
menghapusnya, kita dapat menggunakan POST, PUT, atau DELETE untuk memodifikasi
objek (dalam praktiknya, kebanyakan service menggunakan POST untuk ini).
Contoh Aplikasi menggunakan REST web service
Semua web
service utma di internet sekarang menggunakan REST: Twitter, Yahoo, termasuk
Flickr, del.icio.us, pubsub, bloglines, technorati, dan beberapa yang lain.
eBay dan Amazon menggunakan baik REST maupun SOAP.
Penggunaan SOAP web service
SOAP digunakan
pada aplikasi-aplikasi Enterprise untuk mengintegrasikan penggunaan yang lebih
luas dan banyak aplikasi dan tren yang lain adalah mengintegrasikan dengan
legacy system (sistem lama yg sudah ada sebelumnya). Dalam internet, Google
konsisten dalam mengimplementasikan web service mereka menggunakan SOAP,
kecuali Blogger yang menggunakan XML-RPC.
Gambar
Skema SOAP Web Service
REST vs SOAP
Perusahaan-perusahaan yang
menggunakan REST API belum banyak, API yang mereka gunakan kebanyakan muncul
baru-baru ini. Jadi REST sesungguhnya adalah aturan untuk membuat web service.
Tetapi, mari perhatikan, gunakan konsep "SOAP to wash and your REST when
you tired". Keuntungan utama web service REST yaitu:
·
lightweigt, tidak membutuhkan XML markup
tambahan
·
hasilnya dapat dibaca dengan mudah oleh manusia
(human readable result)
·
mudah untuk dikembangkan, tidak membutuhkan
toolkit
SOAP juga mempunyai beberapa
kelebihan:
·
mudah untuk dikonsumsi (kadang-kadang)
·
rigid (lebih kaku/ketat), dalam type-checking,
harus mematuhi aturan penulisan
·
membutuhkan tools pengembangan
Apakah akses SOAP lebih
mudah/sederhana? Sepertinya tidak! Mari kita lihat perbandingannya sebagai
berikut:
API Flexibility & Simplicity
Kunci metodologi
REST adalah untuk menulis web service menggunakan antarmuka yang sudah tersedia
dan banyak digunakan: URI. Sebagai contoh, service/layanan untuk mengkonversi
mata uang, yang mana seorang user memasukkan simbol mata uang untuk
mengembalikan harga mata uang secara real-time, dapat dilakukan semudah membuat
script yang dapat diakses melalui web server seperti URI:
http://www.ExampleCurrencyBrokerage.com/convert?=us-dollar&value=100&target=pound.
Aplikasi client
atau server dengan dukungan HTTP dapat dengan mudah memanggil service tersebut
dengan command HTTP GET. Berdasar pada bagaimana cara penyedia service menulis
script, hasil respons HTTP kan menjadi lebih simpel seperti beberapa header
standar dan string teks yang mengandung harga terkini untuk symbol yang
diberikan. Atau, dapat berupa dokumen XML.
Metode antarmuka
ini mempunyai keuntungan signifikan dibanding service berbasis SOAP. Developer
dapat mengetahui bagaimana untuk membuat dan memodifikasi sebuah URI untuk
mengakses resource yang berbeda. SOAP, pada sisi lain, membutuhkan pengetahuan
khusus untuk spesifikasi XML, dan kebanyakan developer akan membutuhkan SOAP
toolkit untuk membentuk request dan menguraikan (parsing) hasilnya.
Penggunaan Bandwidth - REST lebih
ringan
Keuntungan lain
dari antarmuka RESTful adalah request dan respon dapat dipendekkan. SOAP
membutuhkan XML wrapper untuk setiap request dan response. Sekali saja
namespace dan penulisan dideklaraskan, empat atau lima digit stock quote dalam
respon SOAP bisa membutuhkan lebih dari sepuluh kali lipat sebanyak byte-byte
respon yang sama ketika diimplementasikan menggunakan REST.
Para pendukung
SOAP berpendapat bahwa penulisan kode yang rigid (kuat) merupakan fitur yang
dibutuhkan dalam aplikasi terdistribusi. Dalam praktiknya, meskipun, keduanya
(aplikasi request dan service) mengetahui tipe data dari waktu ke waktu, tetapi
mengirimkan informasi tersebut dalam bentuk request dan respon hanyalah sebagai
alasan.
Bagaimana
seseorang tahu tipe data dan lokasinya dalam respon-dari waktu ke waktu?
Seperti SOAP, REST masih membutuhkan dokumen yang saling berkaitan yang dapat
menguraikan parameter input dan data output. Kabar baiknya adalah REST cukup
fleksibel sehingga developer dapat menulis file WSDL untuk service-service
tersebut jika dibutuhkan deklarasi secara formal. Jika tidak, deklarasi dapat
sesederhana halaman web yang dapat terbaca manusia (human-readable Web) yang
mengatakan "Berikan service ini sebuah input melali beberapa simbol harga saham,
dalam format q=simbol dan itu akan menghasilkan kembalian harga saat inisebagai
bagian saham sebagai string teks".
Security
Mungkin hal
menarik dari perseteruan REST vs SOAP adalah sudut pandang security (keamanan).
Meskipun SOAP menegaskan bahwa untuk mengirimkan remote procedure calls (RPC)
melalui port standar HTTP adalah cara yang baik untuk memastikan dukungan web
service melalui aturan-aturan yang ada. Namun, para pendukung REST berpendapat
bahwa praktik tersebut adalah sebuah kekurangan utama yang membahayakan
keamanan jaringan. Panggilan-panggilan REST juga dapat melalui HTTP atau HTTPS,
tetapi dengan REST, administrator (firewall) dapat membedakan maksud dari
setiap pesan dengan menganalisis perintah HTTP yang digunakan saat request.
Sebagai contoh, request GET selalu dianggap aman karena ia tidak dapat, menurut
definisi, memodifikasi data apapun. Dan itu hanya dapat meng-query kan data.
Request SOAP
secara tipikal akan menggunakan POST untuk mengkomunikasi dengan service yang
diberikan. Dan tanpa melihat envelope SOAP (tugas yang digunakan untuk
mengkonsumsi keduanya dan tidak disertakan pada kebanyakan firewall) tidak ada
cara untuk mengetahui apakah request tersebut hanya ingin meng-query data atau
menghapus seluruh tabel dari database.
Adapun untuk
otentikasi dan otorisasi, SOAP menempatkan beban pada pengembang aplikasi.
Metodologi REST tidak memperhitungkan fakta bahwa web server sudah memiliki
dukungan untuk tugas-tugas tersebut. Melalui penggunaan sertifikat standar
industri dan sistem manajemen identitas umum, seperti server LDAP,
developer-developer dapat membuat layer jaringan melakukan langkah berat.
Ini tidak hanya
memudahkan para developer, tetapi juga memudahkan administrator, yang dapat menggunakan
sesuatu semudah file ACL untuk mengontrol web service layaknya menggunakan URI
yang lain.
REST tidak Sempurna
Sejujurnya, REST
tidaklah sempurna. REST bukanlah solusi terbaik untuk setiap web service. Data
yang butuh keamanan seharusnya tidak dikirimkan sebagai parameter dalam URI.
Dan data dalam jumlah besar, seperti layanan pembelian, dapat menjadi rumit
bahkan di luar batas URI.
Dan ketika
metode web service diintegrasikan dengan attachment, SOAP adalah juaranya. SOAP
dapat mengirimkan semua teks dan binary-binary tanpa kesalahan. Dalam beberapa kasus, SOAP
sesungguhnya adalah solusi yang tepat. Tetapi sangat penting untuk mencoba REST
terlebih dahulu dan gunakan SOAP hanya bila diperlukan. Ini akan membantu
menjaga pengembangan aplikasi secara sederhana dan mudah diakses.
Untungnya,
filosofi REST dapat ditangkap para developer web service. Versi terbaru dari
spesifikasi SOAP saat ini mengijinkan beberapa tipe service yang dapat
dipaparkan melalui URI (meskipun respon masih berupa pesan SOAP). Demikian pula
platform Microsoft .NET dapat mempublikasikan service-service sehingga dapat
menggunakan request-request GET Semua ini menandakan pergeseran pemikiran
tentang bagaimana membuat interface terbaik untuk web service.
Developer perlu
memahami bahwa pengiriman dan penerimaan pesan SOAL tidak selalu cara terbaik
bagi aplikasi untuk berkomunikasi. Kadang-kadang interface REST sederhana dan
respon plain teks dapat menyelesaikannya dan juga lebih banyak menghemat waktu dan resource
dalam prosesnya.
Type Handling
SOAP menyediakan
aturan penulisan yang ketat sejak mempunyai sekumpulan tipe-tipe data. Oleh
karena itu menjamin bahwa return value (nilai kembalian) aka tersedia secara
langsung dalam tipe native yang berkorespondensi pada platform tertentu. Pengetikan
return value HTTP berbasis API harus diserialisasi dari XML, kemudian baru
disesuaikan cara penulisannya. Ini tidak mewakili banyak usaha, musalnya untuk
bahasa pemrograman dinamis. Faktanya, bahkan pengetikan objek-objek kompleks,
traversing sebuah object sangat mirip dengan traversing XML tree, sehingga
disini tidak ada manfaat yang jelas dalam kemudahan client-side coding.
Kompleksitas Cient-side
Membuat
panggilan ke suatu HTTP API secara signifikan lebih mudah daripada membuat
panggilan ke SOAP API. SOAPAPI membutuhkan library client, membutuhkan
pengenalan, dan butuh kebiasaan. Sedangkan HTTP API adalah asli dari semua
bahasa pemrograman dan hanya melibatkan request HTTP dengan parameter sesuai yang ditambahkan.
Bahkan secara psikologis, tipe yang pertama sedikit tidak memerlukan usaha.
Testing dan TroubleshootingBI
HTTP API juga
mudah untuk di tes dan troubleshoot
karena dapat membangun pangglan dengan tidak lebih dari sekedar browser
dan memeriksa respon dalam jendela browser itu sendiri. Tidak ada tool
trubleshooting yang dibutuhkan untuk menghasilkan siklus request/response.
Dalam hal ini tidak dapat dipungkiri bahwa HTTP berbasis API lebih unggul.
Kompleksitas Server-side
Kebanyakan bahasa pemrograman
membuat kompleksitas server-side menjadi sangat mudah untuk menerangkan sebuah
method melalui SOAP. Serialisasi dan deserialisasi ditangani oleh SOAP Server
Library. Untuk menerangkan metode objek sebagai HTTP API dapat secara relatif
lebih menantang karena memerlukan serialisasi output ke XML. Membuat API REST-y
melbatkan pekerjaan tambahan untuk memetakan jalur URI ke handler spesifik dan untuk mengimpor maksud
permintaan HTTP request ke dalam skema. Banyak framework yang ada membuat tugas
ini lebih mudah dilakukan. Namun demikian, saat ini, hal tersebut masih lebih
mudah untuk mengekspos seperangkat method menggunakan SOAP daripada
mengeksposnya menggunakan HTTP biasa.
Caching
Karena berbasis
HTTP/Rest-ful API dapat dikonsumsi menggunakan request GET sederhana, server
proxy/reverse-proxy dapat melakukan cache atas respon tersebut dengan mudah. Di
sisi yang lain, request SOAP menggunakan POST dan membutuhkan request XML
kompleks untuk dibangun yang akan membuat caching-respon terasa sulit.
KESIMPULAN
Dari penjelasan detail di atas
dapat dikatakan bahwa SOAP tidak semudah itu, SOAP membutuhkan usaha
implementasi yang lebih besar dan pengetahuan di sisi klien, sedangkan web
service berbasis HTTP atau REST-API
membutuhkan implementasi yang lebih besar dan pengetahuan di sisi
server. Adopsi API dapat meningkatkan lebih jauh lagi jika interface berbasis
HTTP disediakan. Faktanya, HTTP berbasis API dengan respon XML/JSON mewakili
yang terbaik dari kedua turunan dan mudah diimplementasikan dalam server
semudah mengkonsumsi melalui server.
Untuk mengkonsumsi web service,
kadang-kadang bingung mengimplementasikan mana yang lebih mudah. Sebagai contoh
Google AdWords web service sangat sulit untuk dikonsumsi (dalam CF apapun),
karena menggunakan header SOAP, dan sejumlah hal lain yang membuatnya sulit.
Sebaliknya, web service REST Amazon kadangkala rumit untuk diuraikan (pase)
karena sangat berulang, dan hasil schema dapat sedikit bervariasi sesuai dengan
apa yang Anda cari.
Arsitektur mana yang Anda pilih,
pastikan pilih yang termudah bagi developer untuk mengaksesnya, dan
tersokumentasi dengan baik. Akhirnya ketika Anda meng-host layanan internet,
hal tersebut adalah kompleksitas sisi klien yang paling penting untuk menarik
klien untuk menggunakan web service Anda.
Web Service SOAP dan RESTful
mempunyai filosofi yang berbeda. SOAP sesungguhnya sebuah protokol komputasi
terdistribusi berbasis XML, dimana REST cenderung masih sangat baru, desain
berbass web. Sebagai catatan SOAP tidak sekompleks yang dikatakan banyak
sumber, SOAP dapat dikatakan kompleks ketika digunakan untuk banyak ekstensi.
Summary
Keuntungan SOAP
- bahasa, platform, dan transport agnostic
- dirancang untuk menangani lingkungan komputasi terdistribusi
- merupakan standar yang berlaku untuk web servis, sehingga mempunyai dukungan yang lebih baik dari standar yang lain (WSDL, WS-*) dan tools dari berbagai vendor
- built-in error handling (faults)
- extensibility
Kelemahan SOAP
- secara konseptual lebih sulit, lebih "heavy-weight" dibanding REST
- lebih "verbose" (membutuhkan lebih banyak pernyataan/kode program)
- sulit untuk dikembangkan, mebutuhkan tools
Keuntungan REST
- bahasa dan platform agnostic
- lebih sederhana/simpel untuk dikembangkan ketimbang SOAP
- mudah dipelajari, tidak bergantung pada tools
- ringkas, tidak membutuhkan layer pertukaran pesan (messaging) tambahan
- secara desain dan filosofi lebih dekat dengan web
- Mengasumsi model point-to-point komunikasi - tidak dapat digunakan untuk lingkungan komputasi terdistribusi di mana pesan akan melalui satu atau lebih perantara
- Kurangnya dukungan standar untuk keamanan, kebijakan, keandalan pesan, dll, sehingga layanan yang mempunyai persyaratan lebih canggih lebih sulit untuk dikembangkan ("dipecahkan sendiri")
- Berkaitan dengan model transport HTTP
Sumber
Anda baru saja membaca artikel yang berkategori Web Service
dengan judul "Perbedaan Web Service Soap Dengan Rest ( Soap Vs Rest Web Service)". Anda bisa bookmark halaman ini dengan URL https://3goldenbooks.blogspot.com/2013/10/difference-of-rest-and-soap-web-service.html.
0 komentar
Posting Komentar