Anda di halaman 1dari 11

Web Service SOAP vs REST, Mana yang Lebih Baik?

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.

RESTful vs SOAP

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

converted by Web2PDFConvert.com
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.

Apakah REST web service itu?

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

Seberapa Populer kah REST itu?

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.

Bagaimana dengan SOAP?

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.

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.

converted by Web2PDFConvert.com
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

converted by Web2PDFConvert.com
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 Troubleshooting

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.

converted by Web2PDFConvert.com
REST & SOAP Scorecard

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

converted by Web2PDFConvert.com
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

Kelemahan REST
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

Resource: http://greatgandhi.wordpress.com/2010/06/16/soap-vs-rest-%E2%80%93-the-best-webservice/

29 40

Postingan Terkait

converted by Web2PDFConvert.com
New Fat Burner Takes GNC by Storm
ProbioSlim

Padan Kata-Kata Ilmiah dalam Bahasa Inggris ke Bahasa Indonesia

New Sleep Aid Takes CVS by Storm


PeakLife

converted by Web2PDFConvert.com
Read Books? Here's The Worst Kept Secret Among Bookworms
The Book Insider

Tutorial Instalasi PhoneGap pada Android

Fungsi dan Penggunaan File HTACCESS pada Server

Unable to play video. Neither flash nor


html5 is supported!

Ads by Shareaholic

URL versi pendek untuk postingan ini yaitu: http://wp.me/p1kJe9-mr

Tagged on: rest soap web service

Konsep Dasar Pemrograman Berorientasi Objek Mengenal WSDL dan Strukturnya dalam Web Service

converted by Web2PDFConvert.com
1 Comment Aditya Rizki
1 Login

Recommend Share Sort by Best

Join the discussion

Joshua Adriel Favian 8 months ago


Terimakasih atas infonya mas, sangat memberikan pencerahan :D
Reply Share

ALSO ON ADITYA RIZKI


Tutorial Teknik Digital : Rangkaian Pencacah (Counter) Tutorial Implementasi REST dengan PHP (GET, POST,
2 comments a year ago DELETE)
Aditya Rizki coba dikembangan sendiri ya ;) 7 comments a year ago
Wahyu Dot Php tolong dong gan, kok begini ya ?

Tutorial Pemrograman Berorientasi Obyek dengan C++ : Tutorial Teknik Komputasi dengan Scilab : Menggambar
Inheritance (Studi Kasus) Grafik (Pendahuluan)
9 comments a year ago 1 comment a year ago
gus kok gak muncul ya... header " " , gantinya hanya " " Furqon Aji Yudhistira Terima kasih, sangat bermanfaat
untuk menyelesaikan laporan Praktikum saya :)

Subscribe d Add Disqus to your site Privacy

A dog is not considered a good dog because he is a good barker. A man is not considered a good man because he is a good talker.
Buddha

TERPOPULER HARI INI


Tutorial Instalasi Eclipse dan Android SDK (Windows)

Konsep Dasar Pemrograman Berorientasi Objek

[Review] Pesan Anarki di Album Ke-8 Superman Is Dead

Tutorial Teknik Digital : Teorema Boolean dan Rangkaian Kombinatorial

Sistem Kerja Radio I : Transmitter

Dasar-Dasar Sistem Telekomunikasi

Tutorial Teknik Digital : Rangkaian Pencacah (Counter)

TERBARU
Membaca Judul Buku Mojok

Gema Augmented Reality di Sekitar Kita

Napak Tilas Mendoan dan Usaha Merevisi Mental Tempe

Apple Music, Please Welcome!

Memburu Senja di Pulau Seribu Pura

Dari Gemerlap Economics Jazz Bersama Saksofonis Dave Koz

Memprediksi Juara Liga Champions Berdasarkan Tren Pencarian di Google

ARSIP
Select Month

converted by Web2PDFConvert.com
TOPIK

Android digital html5 Indonesia internet jejaring sosial jess Komputasi komputer konser musik mysql PBO PHP resensi Review
rock Scilab sistem pakar telekomunikasi

SITUS KAWAN
Alvian Edo Kautsar

Anindita Saktiaji

Arif Febriyanto

Arlian Buana

Belinda CH

Canggih Puspo W.

Fahri Salam

Galdita A. C.

Iqbal Kautsar

Iwan Setyawan A

Ninan Kara GN

Puthut EA

Rifqi Muhamad

Tulus Hamdani

Wisnu Pasetya Utomo

Zakiyah D.

TAUTAN

Copyright 2015 Aditya Rizki's Blog. Powered by WordPress. Theme: Esteem by ThemeGrill.

converted by Web2PDFConvert.com
converted by Web2PDFConvert.com