REST vs SOAP

Berikut ini artikel tentang REST vs SOAP yang saya terjemahkan secara bebas dari http://geeknizer.com/rest-vs-soap-using-http-choosing-the-right-webservice-protocol. Semoga saja bermanfaat, setidaknya untuk memenuhi tugas saya pada mata kuliah Service-Oriented Architecture.

Web servis merupakan kunci integrasi aplikasi-aplikasi yang berbeda platform, bahasa, bahkan sistemnya. Jadi, tak salah jika Anda menyebutnya sebagai “titik ketemunya bisnis”.

Saya sudah memakai HTTP dan SOAP sejak beberapa tahun lalu, sementara REST baru belakangan ini. SOAP merevolusi RPC dan loose coupling melampaui pembatasan yang dibuat oleh protokol sebelumnya. Saya cenderung banyak menggunakan API HTTP sederhana  dengan format respon XML atau JSON sebagai lawan SOAP. Mari kita bahas semua aspeknya satu per satu.

Sebelum kita mulai, mari kita lihat istilah-istilah dasarnya

• SOAP singkatan dari Simple Object Access Protocol.
• HTTP berbasis API maksudnya adalah API yang dipanggil sebagai satu atau lebih URI HTTP dan respon umumnya dalam format XML/JSON. Skema responnya pun berbeda-beda setiap objeknya.
• REST di sisi lain merupakan elemen penggunaan URI yang distandarkan, dan juga menambah pentingnya verba HTTP yang dipakai, seperti GET, POST, PUT, dan sebagainya.

Meskipun pada tahun-tahun terakhir ini kita lihat pertumbuhan jumlah web servis, meski publisitas SOAP sudah berkurang. Arsitek internet memiliki alasan bagus telah meminggirkan SOAP, karena ada metode yang lebih baik untuk membangun web servis dalam bentuk Representational State Transfer (REST).

REST lebih merupakan filosofi tua ketimbang teknologi baru, tetapi merupakan wujud yang kemudian lahir sebagai teknologi. SOAP terlihat melompat, memulai fase berikutnya dari pengembangan internet dengan sejumlah spesifikasi baru, sedang REST berfilosofi bahwa prinsip-prinsip yang ada dan protokol web sudah cukup untuk membuat web servis yang baik. Ini berarti bahwa pengembang yang paham tentang HTTP dan XML dapat langsung mulai membangun web servis, tanpa perlu ada toolkit yang biasanya tidak mereka gunakan untuk pengembangan aplikasi Internet.

Pada arsitektur RESTful, resource kunci diidentifikasi – dapat berupa entitas, koleksi, atau apapun yang oleh desainer dirasa cocok untuk memiliki URI sendiri. Metode standar – pada kasus ini, verba HTTP – dipetakan ke resource dengan semantik khusus. Semua resource mengimplementasikan interface yang seragam. Dimensi tipe konten, yang memungkinkan representasi berbeda dari resource (seperti XML, HTML, dan plain teks) sebagaimana kemungkinan link ke resource ke representasi resource. Gunakan imajinasimu, misalnya dengan GET pada “/customer/4711” akan mengembalikan dokumen yang berisi link pada “/order/xyz.”

Saya melihat banyak web servis dibuat dengan arsitektur bergaya REST daripada dengan SOAP. Mari kita lihat sekilas tentang REST.

Apa itu Web Servis REST

Representational State Transfer atau REST pada dasarnya berarti bahwa tiap URL yang unik adalah representasi dari beberapa objek. Kamu bisa mendapatkan konten objek itu menggunakan HTTP GET, untuk menghapusnya, mungkin memakai POST, PUT, atau DELETE untuk memodifikasi objek. Pada praktiknya, kebanyakan web servis memakai POST.

Sepopuler apa REST itu?

Semua web servis besar di internet sekarang ini menggunakan REST: Twitter, web servis Yahoo, Flickr, del.icio.us, pubsub, bloglines, technorati, dan beberapa lainnya. eBay dan Amazon memiliki web servis dengan REST dan SOAP.

Lalu SOAP?

SOAP banyak digunakan dalam aplikasi enterprise untuk mengintegrasikan macam-macam aplikasi dan tren lainnya ke sistem legasi (yang sudah ada sebelumnya). Di internet, Google konsisten mengimplementasikan web servisnya menggunakan SOAP, dengan pengecualian Blogger yang menggunakan XML-RPC. Tetapi sekarang Google sudah mulai  berali ke REST.

REST vs SOAP

Perusahaan yang menggunakan API REST belum terlalu lama, dan API mereka keluar tahun ini atau akhir tahun lalu (artikel ini ditulis tahun 2009-red). Jadi REST merupakan masalah selera dalam membuat web servis. Tetapi, mari kita lihat – Pakai SOAP (sabun) untuk mencuci, dan kamu REST (istirahat) jika lelah. Keuntungan utama dari web servis REST adalah:

• Ringan – tidak banyak markup xml yang berlebihan
• Hasilnya mudah dibaca dan dipahami orang
• Mudah membuatnya – tidak perlu toolkit tertentu

SOAP juga memiliki keuntungan:

• Mudah digunakan – kadang
• Kaku – cek tipe, mengikuti sebuah kontrak
• Perlu tool pengembangan khusus

Jadi, apakah SOAP yand disebut Simple (sederhana) Object Access sebegitu simple? Saya rasa ini penamaan yang salah.

Mari diskusikan semua perbandingannya

Fleksibilitas dan Simpelnya API

Metodologi kunci yang dipakai REST adalah menulis web servis menggunakan interface yang sudah terkenal dan banyak dipakai: URI. Contohnya, menampilkan servis konversi mata uang, dimana user memasukkan simbol mata uang untuk mendapatkan harga mata uang yang diinginkan secara real-time, dapat menjadi sesederhana seperti membuat sebuah skrip yang bisa diakses melalui web server dengan URI http://www.ExampleCurrencyBrokerage.com/convert?=us-dollar&value=100&target=pound.

Jadi, klien atau aplikasi server manapun dengan dukungan HTTP dapat dengan mudah memanggil servis tersebut dengan perintah HTTP GET. Tergantung bagaimana provider servis menulis skrip, respon HTTP yang dihasilkan mungkin  sederhana seperti beberapa header standar dan teks yang berisi harga mata uang untuk dengan simbol yang diinginkan. Atau bisa juga berupa dokumen XML.

Metode interface ini memiliki kelebihan dibanding servis dengan SOAP. Developer dapat memahami bagaimana membuat dan memodifikasi URI untuk mengakses resource web yang berbeda. SOAP, di sisi lain, membutuhkan pengetahuan khusus tentang spesifikasi XML, dan kebanyakan developer akan membutuhkan toolkit SOAP untuk membuat permintaan dan menguraikan hasilnya.

Penggunaan bandwidth – REST lebih ringan

Keuntungan lain menggunakan interface RESTful adalah request dan responnya dapat dibuat singkat. SOAP membutuhkan atribut XML pada setiap request dan respon. Sekali namespace dan pengetikan dideklarasikan, empat atau lima tanda kutip pada respon SOAP diperlukan lebih dari 10 kali, sebanyak itu untuk mendapatkan hasil yang sama dengan REST.

Para pendukung SOAP beralasan bahwa aturan penulisan yang ketat adalah hal penting dalam aplikasi terdistribusi. Praktiknya, baik aplikasi yang merequest maupun servisnya sama-sama mengetahui tipe data, jadi transfer informasi seperti itu dalam request dan respon tidaklah berguna.

Bagaimana kita tahu tipe datanya dan lokasi dimana responnya? Seperti SOAP, REST tetap memerlukan dokumen terkait yang merupakan garis besar parameter input dan outputnya. Bagusnya, REST cukup fleksibel sehingga developer dapat menuliskan file WSDL untuk servisnya jika memang deklarasi formalnya diperlukan. Sebaliknya, deklarasi dapat disederhanakan sehingga mudah dibaca dan dipahami. Web cukup mengatakan, “Berilah servis ini beberapa simbol mata uang, dengan format q=symbol, dan servis akan memberi nilai mata uang yang diinginkan dalam format teks.”

Keamanan

Mungkin saja aspek paling menarik dari perdebatan REST vs SOAP adalah perspektif keamanan (sekuriti). SOAP mempertahankan konsep bahwa mengirim remote procedure call (RPC) melalui port HTTP adalah cara yang bagus untuk memastikan web servis mendukung berbagai batasan organisasi. Sementara itu, pendukung REST beralasan bahwa praktiknya, cacat desain utamalah yang membahayakan keamanan jaringan. REST juga menggunakan HTTP atau HTTPS, tetapi dengan REST administrator atau firewall dapat melihat maksud setiap pesan dengan menganalisis perintah HTTP yang dipakai dalam request. Sebagai contoh, request GET dapat selalu diartikan aman karena, secara definisi, perintah ini tidak dapat memodifikasi data. Perintah ini hanya bisa melakukan query terhadap data.

Request SOAP biasanya akan menggunakan perintah POST untuk berkomunikasi dengan servis tertentu. Dan tanpa melihat ke dalam amplop SOAP, sebuah perintah yang resource-consuming (konsumtif terhadap sumber daya) dan tidak dilewatkan pada kebanyakan firewall, tak ada jalan untuk mengetahui apakah request tersebut hanya ingin melakukan query data atau menghapus seluruh tabel pada database.

Untuk autentifikasi dan autorisasi, SOAP memberatkan bagi developer aplikasi. Sementara metodologi REST menganggap bahwa urusan tersebut sudah di-support oleh web server. Melalui penggunaan sertifikasi standar industri dan sistem manajemen identitas, seperti server LDAP, developer dapat membuat layer network melakukan hal-hal yang berat.

Hal ini tidak hanya membantu para pengembang, tetapi memudahkan beban para administrator, yang dapat menggunakan sesuatu yang sederhana seperti ACL file untuk mengelola web servis mereka dengan cara yang sama mereka akan setiap URI lainnya.

REST tidaklah sempurna

REST tidaklah sempurna, dan bukan solusi terbaik utnuk setiap web servis. Data yang perlu diamankan tidak boleh dikirim sebagai parameter dalam URI. Dan jumlah data yang besar, seperti detail belanja, dapat menjadi tidak praktis atau tidak bisa dipakai dalam URI.

Dan ketika menggunakan attachment (pelampiran file), SOAP unggul. SOAP dapat mengirimkan teks dan binary. Untuk kasus seperti ini, SOAP merupakan solusi yang solid. Tetapi penting untuk memakai REST terlebih dahulu dan menggunakan SOAP jika memang perlu. Ini membantu menjaga pengembangan aplikasi tetap sederhana dan mudah diakses.

Untungnya, filosofi REST cukup menarik bagi para developer web servis. Versi terakhir spesifikasi SOAP memungkinkan servis jenis tertentu diekspos melalui URI (meskipun responnya tetap berupa pesan SOAP). Sama halnya dengan pengguna platform .NET mempublish servis sehingga mereka menggunakan request GET. Semua ini menggeser pemikiran tentang interface web servis yang terbaik.

Developer perlu paham bahwa mengirim dan menerima pesan SOAP tidaklah selalu menjadi jalan terbaik bagi aplikasi untuk saling berkomunikasi. Kadang interface REST yang sederhana dan sebuah respon plain teks dapat melakukannya, dan tentu akan menghemant waktu dan sumber daya dalam prosesnya.

Aturan Penulisan
SOAP memberi aturan penulisan yang relafit lebih kuat karena ada tipe data tertentu yang didukung. Hal ini menjamin bahwa nilai yang dikembalikan akan tersedia langsung dalam bentuk tipe asli dalam plaftorm tertentu. Dalam hal API berbasis HTTP nilai kembali harus di-deserial-kan dari XML, dan kemudian di-type-cast (diubahsuaikan). Hal ini barangkali tidak perlu banyak usaha, terutama jika menggunakan bahasa dinamis. Bahkan pada objek yang kompleks, membahas objek tersebut hampir sama dengan membahasa sebuah pohon XML, jadi tidak ada keuntungan dilihat dari kemudahan coding oleh klien.

Kompleksitas di Sisi Klien

Membuat panggilan ke sebuah API berbasis HTTP sungguh mudah daripada memanggil ke API berbasis SOAP. API berbasis SOAP membutuhkan library klien, sebuah potongan atau kurva belajar. Yang pertama adalah asli ke semua bahasa pemrograman dan hanya perlu membuat rekues  HTTP dengan parameter yang sesuai. Bahkan secara psikologis yang pertama sepertinya tidak perlu banyak usaha.

Pengujian dan Trobleshooting

Adalah mudah untuk menguji dan troubleshoot suatu API HTTP karena kita dapat membangun sebuah panggilan dengan cukup sebuah browser dan mengecek respon di dalam jendela browser itu juga. Tak perlu tool khusus untuk membuat request atau siklus respon. Di sinilah letaknya kekuatan utama API berbasis HTTP.

Kompleksistas di Sisi Server

Kebanyakan bahasa program membuat mudah metode-metode menggunakan SOAP. Serialisasi dan deserialisasi ditangani oleh library server SOAP. Untuk membuka metode objek sebagai sebuah API HTTP lebih menantang karena membutuhkan serialisasi otput ke XML. Membuat API berbasis REST meliputi pekerjaan tambahan untuk memetakan jalur URI ke handler khusus dan untuk mengimpor makna request HTTP pada skemanya. Tentu saja banyak framework untuk memudahkan tugas ini. Meskipun saat ini, masih lebih mudah membuat metode menggunakan SOAP daripada dengan HTTP biasa.

Caching

Sejak API berbasis HTTP/Rest-full dapat digunakan dengan menggunakan request GET yang sederhana, proksi server/proksi-balik dapat membuat cache responnya dengan mudah. Di sisi lain, rekues SOAP memakai POST dan membutuhkan rekues XML yang rumit untuk dibuat yang membuat cache respon menjadi sulit.

Kesimpulan

Pada akhirnya aku percaya bahwa SOAP tidaklah sederhana. SOAP memerlukan upaya implementasi yang lebih besar sekaligus pemahaman pada sisi klien. Sementara API yang berbasis HTTP atau berbasis REST membutuhkan upaya lebih dari sisi server. Adopsi API dapat meningkatkan bila interface berbasis HTTP disediakan. Faktanya, API berbasis HTTP dengan respon XML/JSON dalam implementasi pada sisi server semudah penggunaannya oleh klien.

Untuk penggunaan web servis, kadang seperti undian untuk menentukan mana yang mudah. Sebagai contoh, webservis Google’s Adwords sangatlah susah untuk dipakai, dimana dia menggunakan header SOAP dan berbagai hal lain yang membuat semakin sulit. Sebaliknya, web servis Amazon dengan REST terkadang seperti menipu dalam menguraikan karena algoritma penyarangan yang sangat dalam, dan skema hasilnya bisa sangat jauh dari apa yang kita cari.

Arsitektur apapun yang kita pilih, pastikan bahwa itu mudah bagi developer untuk mengaksesnya dan terdokumentasi dengan baik. Pada akhirnya, ketika Anda membuat web servis di internet, adalah masalah kompleksitas yang dihadapi pengguna yang menjadi masalah ketertarikan mereka menggunakan web servis Anda. Pilihlah dengan bijak.

Read more: http://geeknizer.com/rest-vs-soap-using-http-choosing-the-right-webservice-protocol/#ixzz2AvopFlOt

Fuihh… Sekian dulu…