Pertanyaan SOAP vs REST (perbedaan)


Saya telah membaca artikel tentang perbedaan antara SOAP dan REST sebagai protokol komunikasi layanan web, tetapi saya pikir bahwa keuntungan terbesar untuk REST over SOAP adalah:

  1. REST lebih dinamis, tidak perlu membuat dan memperbarui UDDI.

  2. REST tidak terbatas pada format XML. Layanan web REST dapat mengirim teks biasa, JSON, dan juga XML.

Tapi SOAP lebih standar (Ex; keamanan).

Jadi, apakah saya benar dalam hal ini?


987
2017-11-09 23:11


asal


Jawaban:


Sayangnya, ada banyak kesalahan informasi dan kesalahpahaman seputar REST. Bukan hanya pertanyaan Anda dan dijawab oleh @cmd mencerminkan mereka, tetapi sebagian besar pertanyaan dan jawaban terkait dengan subjek di Stack Overflow.

SOAP dan REST tidak dapat dibandingkan secara langsung, karena yang pertama adalah protokol (atau setidaknya mencoba untuk menjadi) dan yang kedua adalah gaya arsitektur. Ini mungkin salah satu sumber kebingungan di sekitarnya, karena orang cenderung memanggil REST API HTTP apa pun yang tidak SOAP.

Mendorong sedikit dan mencoba untuk membuat perbandingan, perbedaan utama antara SOAP dan REST adalah tingkat penggabungan antara klien dan implementasi server. Klien SOAP berfungsi seperti aplikasi desktop khusus, digabungkan dengan erat ke server. Ada kontrak kaku antara klien dan server, dan semuanya diharapkan akan rusak jika salah satu pihak mengubah apa pun. Anda perlu pembaruan konstan mengikuti perubahan apa pun, tetapi lebih mudah untuk memastikan apakah kontrak sedang diikuti.

Klien REST lebih mirip browser. Ini adalah klien umum yang tahu cara menggunakan protokol dan metode standar, dan aplikasi harus sesuai dengan itu. Anda tidak melanggar standar protokol dengan membuat metode ekstra, Anda memanfaatkan metode standar dan membuat tindakan dengan mereka pada jenis media Anda. Jika dilakukan dengan benar, ada lebih sedikit kopling, dan perubahan dapat ditangani dengan lebih baik. Seorang klien seharusnya memasuki layanan REST dengan pengetahuan nol tentang API, kecuali titik masuk dan jenis media. Dalam SOAP, klien membutuhkan pengetahuan sebelumnya tentang segala hal yang akan digunakan, atau bahkan tidak akan memulai interaksi. Selain itu, klien REST dapat diperpanjang oleh kode-on-demand yang disediakan oleh server itu sendiri, contoh klasik yang kode JavaScript digunakan untuk mendorong interaksi dengan layanan lain di sisi-klien.

Saya pikir ini adalah poin penting untuk memahami apa REST tentang, dan bagaimana hal itu berbeda dari SOAP:

  • REST adalah protokol independen. Ini tidak digabungkan ke HTTP. Hampir seperti Anda dapat mengikuti tautan ftp di situs web, aplikasi REST dapat menggunakan protokol apa pun yang memiliki skema URI standar.

  • REST bukan pemetaan CRUD ke metode HTTP. Baca baca ini jawab untuk penjelasan rinci tentang itu.

  • REST adalah terstandardisasi seperti bagian yang Anda gunakan. Keamanan dan otentikasi dalam HTTP distandardisasi, jadi itulah yang Anda gunakan saat melakukan REST melalui HTTP.

  • REST bukan REST without hypermedia dan HATEOAS. Ini berarti bahwa klien hanya mengetahui titik masuk URI dan sumber daya seharusnya mengembalikan tautan yang harus diikuti klien. Generator dokumentasi mewah yang memberikan pola URI untuk semua hal yang dapat Anda lakukan di REST API benar-benar kehilangan intinya. Mereka tidak hanya mendokumentasikan sesuatu yang seharusnya mengikuti standar, tetapi ketika Anda melakukan itu, Anda menggabungkan klien ke satu momen tertentu dalam evolusi API, dan setiap perubahan pada API harus didokumentasikan dan diterapkan, atau akan hancur.

  • REST adalah gaya arsitektur web itu sendiri. Ketika Anda memasukkan Stack Overflow, Anda tahu apa itu Pengguna, Pertanyaan dan Jawaban, Anda tahu jenis media, dan situs web menyediakan tautan kepada mereka. API REST harus melakukan hal yang sama. Jika kami mendesain web dengan cara orang berpikir REST harus dilakukan, daripada memiliki laman beranda dengan tautan ke Pertanyaan dan Jawaban, kami akan memiliki dokumentasi statis yang menjelaskan bahwa untuk melihat pertanyaan, Anda harus mengambil URI stackoverflow.com/questions/<id>, ganti id dengan Question.id dan tempelkan di browser Anda. Itu omong kosong, tapi itulah yang banyak orang pikirkan REST.

Poin terakhir ini tidak dapat ditekankan cukup. Jika klien Anda membuat URI dari template dalam dokumentasi dan tidak mendapatkan tautan dalam representasi sumber daya, itu bukan REST. Roy Fielding, penulis REST, menjelaskan hal ini di posting blog ini: API REST harus di-hypertext.

Dengan pemikiran di atas, Anda akan menyadari bahwa sementara REST mungkin tidak terbatas pada XML, untuk melakukannya dengan benar dengan format lain, Anda harus merancang dan menstandardisasi beberapa format untuk tautan Anda. Hyperlink adalah standar dalam XML, tetapi tidak dalam JSON. Ada standar draf untuk JSON, seperti HAL.

Akhirnya, REST bukan untuk semua orang, dan bukti dari itu adalah bagaimana kebanyakan orang memecahkan masalah mereka dengan sangat baik dengan API HTTP yang secara keliru mereka sebut REST dan tidak pernah keluar dari itu. REST sulit dilakukan kadang-kadang, terutama di awal, tetapi membayar dari waktu ke waktu dengan evolusi yang lebih mudah di sisi server, dan ketahanan klien terhadap perubahan. Jika Anda membutuhkan sesuatu yang dilakukan dengan cepat dan mudah, jangan repot-repot untuk mendapatkan REST yang benar. Itu mungkin bukan yang Anda cari. Jika Anda membutuhkan sesuatu yang harus tetap online selama bertahun-tahun atau bahkan puluhan tahun, maka REST adalah untuk Anda.


1461
2017-11-10 00:45



REST vs SOAP aku s tidak pertanyaan yang tepat untuk ditanyakan.

RESTtidak seperti SOAP aku s tidak sebuah protokol.

REST adalah gaya arsitektur dan a Desain untuk arsitektur perangkat lunak berbasis jaringan.

REST konsep disebut sebagai sumber daya. Representasi sumber daya harus tanpa kewarganegaraan. Ini diwakili melalui beberapa jenis media. Beberapa contoh jenis media termasuk XML, JSON, dan RDF. Sumber daya dimanipulasi oleh komponen. Komponen meminta dan memanipulasi sumber daya melalui antarmuka seragam standar. Dalam kasus HTTP, antarmuka ini terdiri dari ops HTTP standar, mis. GET, PUT, POST, DELETE.

Pertanyaan @ Abdulaziz memang menerangi fakta itu REST dan HTTP sering digunakan bersama-sama. Hal ini terutama karena kesederhanaan HTTP dan pemetaannya yang sangat alami terhadap prinsip RESTful.

Prinsip-Prinsip Dasar REST

Komunikasi Server-Klien

Arsitektur client-server memiliki pemisahan kekhawatiran yang sangat berbeda. Semua aplikasi yang dibangun dengan gaya RESTful harus juga client-server pada prinsipnya.

Tanpa kewarganegaraan

Setiap permintaan klien ke server mengharuskan negara sepenuhnya diwakili. Server harus dapat sepenuhnya memahami permintaan klien tanpa menggunakan konteks server atau status sesi server. Oleh karena itu semua negara harus disimpan pada klien.

Cacheable

Pembatasan cache dapat digunakan, sehingga memungkinkan data respons ditandai sebagai dapat disimpan atau tidak dapat di-cache. Data apa pun yang ditandai sebagai dapat disimpan dapat digunakan kembali sebagai tanggapan atas permintaan berikutnya yang sama.

Antarmuka Seragam

Semua komponen harus berinteraksi melalui satu antarmuka seragam. Karena semua interaksi komponen terjadi melalui antarmuka ini, interaksi dengan layanan yang berbeda sangat sederhana. Antarmukanya sama! Ini juga berarti bahwa perubahan implementasi dapat dilakukan secara terpisah. Perubahan semacam itu, tidak akan mempengaruhi interaksi komponen fundamental karena antarmuka seragam selalu tidak berubah. Salah satu kelemahannya adalah Anda terjebak dengan antarmuka. Jika pengoptimalan dapat diberikan ke layanan tertentu dengan mengubah antarmuka, Anda kurang beruntung karena REST melarang ini. Namun, di sisi baiknya, REST dioptimalkan untuk web, maka popularitas REST yang luar biasa melampaui HTTP!

Konsep di atas mewakili mendefinisikan karakteristik REST dan membedakan arsitektur REST dari arsitektur lain seperti layanan web. Penting untuk dicatat bahwa layanan REST adalah layanan web, tetapi layanan web tidak selalu merupakan layanan REST.

Lihat blog ini pos di Prinsip Desain REST untuk detail lebih lanjut tentang BERISTIRAHAT dan peluru yang disebutkan di atas.

EDIT: perbarui konten berdasarkan komentar


245
2017-11-09 23:19



SABUN MANDI (Protokol Akses Objek Sederhana) dan istirahat (Transfer Negara Representasi) keduanya cantik dengan cara mereka. Jadi saya tidak membandingkannya. Sebaliknya, saya mencoba untuk menggambarkan gambar, ketika saya lebih suka menggunakan REST dan ketika SOAP.

Apa itu muatan? 

Ketika data dikirim melalui Internet, setiap unit yang dikirimkan mencakup informasi header dan data aktual yang dikirim. Header mengidentifikasi sumber dan tujuan paket, sedangkan data aktual disebut sebagai payload. Secara umum, payload adalah data yang dibawa atas nama aplikasi dan data yang diterima oleh sistem tujuan.

Sekarang, misalnya, saya harus mengirim Telegram dan kita semua tahu bahwa biaya telegram akan bergantung pada beberapa kata.

Jadi beritahu saya di antara di bawah ini sebutkan dua pesan ini, mana yang lebih murah untuk dikirimkan?

<name>Arin</name>

atau

"name": "Arin"

Saya tahu jawaban Anda akan menjadi yang kedua meskipun keduanya mewakili pesan yang sama yang kedua lebih murah mengenai biaya.

Jadi saya mencoba mengatakan itu, mengirim data melalui jaringan dalam format JSON lebih murah daripada mengirimnya dalam format XML mengenai payload.

Berikut adalah manfaat atau keuntungan pertama dari REST over SOAP. SOAP hanya mendukung XML, tetapi REST mendukung format yang berbeda seperti teks, JSON, XML, dll. Dan kita sudah tahu, jika kita menggunakan Json maka pasti kita akan berada di tempat yang lebih baik mengenai muatan.

Sekarang, SOAP mendukung satu-satunya XML, tetapi juga memiliki kelebihannya. 

Sangat! Bagaimana?

SOAP bergantung pada XML dalam tiga cara Amplop - yang menentukan apa yang ada di pesan dan cara memprosesnya.

Satu set aturan pengkodean untuk tipe data, dan akhirnya tata letak panggilan prosedur dan tanggapan dikumpulkan.

Amplop ini dikirim melalui transportasi (HTTP / HTTPS), dan RPC (Remote Procedure Call) dijalankan, dan amplop dikembalikan dengan informasi dalam dokumen berformat XML.

Yang penting adalah itu salah satu kelebihan SOAP adalah penggunaan "Generik" transportasi tapi REST menggunakan HTTP / HTTPS. SOAP dapat menggunakan hampir semua transportasi untuk mengirim permintaan tetapi REST tidak bisa. Jadi di sini kami mendapat keuntungan menggunakan SOAP.

Seperti yang sudah saya sebutkan di paragraf di atas “REST menggunakan HTTP / HTTPS”, jadi sedikit lebih dalam pada kata-kata ini.

Ketika kita berbicara tentang REST melalui HTTP, semua langkah keamanan yang diterapkan HTTP diwariskan, dan ini dikenal sebagai tingkat keamanan transportasi dan hanya mengamankan pesan sementara itu di dalam kawat tetapi setelah Anda mengirimkannya di sisi lain, Anda tidak tahu berapa banyak tahapan yang harus dilalui sebelum mencapai titik sebenarnya tempat data akan diproses. Dan tentu saja, semua tahapan itu bisa menggunakan sesuatu yang berbeda dari HTTP.Jadi Istirahat tidak sepenuhnya aman, bukan?

Tetapi SOAP mendukung SSL sama seperti REST juga itu juga mendukung WS-Security yang menambahkan beberapa fitur keamanan perusahaan. WS-Security menawarkan perlindungan dari penciptaan pesan untuk konsumsi. Jadi untuk keamanan tingkat transportasi, celah apa pun yang kami temukan yang dapat dicegah menggunakan WS-Security.

Terlepas dari itu, seperti REST dibatasi oleh protokol HTTP-nya sehingga dukungan transaksi tidak sesuai dengan ACID dan tidak dapat memberikan komitmen dua fase di seluruh sumber daya transnasional yang didistribusikan.

Tetapi SOAP memiliki dukungan komprehensif untuk keduanya Manajemen transaksi berbasis ACID untuk transaksi jangka pendek dan manajemen transaksi berbasis kompensasi untuk transaksi jangka panjang. Ini juga mendukung dua fase berkomitmen di seluruh sumber daya terdistribusi.

Saya tidak menarik kesimpulan apa pun, tetapi saya akan lebih memilih layanan web berbasis SOAP sementara keamanan, transaksi, dll. Adalah perhatian utama.

Berikut adalah "The Java EE 6 Tutorial" di mana mereka katakan Desain RESTful mungkin tepat ketika kondisi berikut terpenuhi. Coba lihat.

Semoga Anda menikmati membaca jawaban saya.


189
2018-06-14 19:48



BERISTIRAHAT(KEMBALIpresentasional State Transfer)
REST adalah gaya arsitektur. Tidak begitu banyak standar seperti SOAP. REST adalah untuk mengekspos API Publik (yaitu API Facebook, Google Maps API) melalui internet untuk menangani operasi CRUD pada data. REST difokuskan pada pengaksesan sumber daya yang diberi nama melalui satu antarmuka yang konsisten.

SABUN MANDI(Slakukan HAImenyangkal SEBUAHccess Protocol)
SOAP membawa protokolnya sendiri dan berfokus pada mengekspos potongan logika aplikasi (bukan data) sebagai layanan. SOAP mengekspos operasi. SOAP difokuskan untuk mengakses operasi bernama, setiap operasi menerapkan beberapa logika bisnis. Meskipun SOAP sering disebut sebagai Layanan web ini keliru. SOAP memiliki sangat sedikit jika ada hubungannya dengan Web. REST menyediakan true Layanan web berdasarkan URI dan HTTP.

Mengapa REST? 

  • Karena REST menggunakan HTTP standar, ini jauh lebih sederhana dari sebelumnya.
  • REST lebih mudah diterapkan, membutuhkan lebih sedikit bandwidth dan sumber daya.
  • REST memungkinkan banyak format data berbeda karena SOAP hanya mengizinkan XML.
  • REST memungkinkan dukungan yang lebih baik untuk klien browser karena dukungannya untuk JSON.
  • REST memiliki kinerja dan skalabilitas yang lebih baik. Baca REST dapat di-cache, bacaan berbasis SOAP tidak dapat di-cache.
  • Jika keamanan bukan masalah utama dan kami memiliki sumber daya yang terbatas. Atau kami ingin membuat API yang akan mudah digunakan oleh pengembang lain secara publik, maka kita harus menggunakan REST.
  • Jika kita membutuhkan operasi CRUD Stateless maka pergi dengan REST.
  • REST umumnya digunakan di media sosial, obrolan web, layanan seluler, dan API Publik seperti Google Maps.
  • Layanan RESTful mengembalikan berbagai MediaTypes untuk sumber daya yang sama, tergantung pada parameter header permintaan "Terima" sebagai application/xml atau application/json untuk POST dan /user/1234.json atau DAPATKAN /user/1234.xml untuk GET.
  • Layanan REST dimaksudkan untuk dipanggil oleh aplikasi sisi klien dan bukan pengguna akhir secara langsung.
  • ST di REST berasal State Transfer. Anda mentransfer keadaan di sekitar alih-alih memiliki server menyimpannya, ini membuat layanan REST dapat skalabel.

Mengapa SOAP? 

  • SOAP sangat tidak mudah untuk diimplementasikan dan membutuhkan lebih banyak bandwidth dan sumber daya.
  • Permintaan pesan SOAP diproses lebih lambat dibandingkan dengan REST dan tidak menggunakan mekanisme cache web.
  • WS-Security: Sementara SOAP mendukung SSL (seperti REST), SOAP juga mendukung WS-Security yang menambahkan beberapa fitur keamanan perusahaan.
  • WS-AtomicTransaction: Perlu ACID Transaksi melalui layanan, Anda akan memerlukan SOAP.
  • WS-ReliableMessaging: Jika aplikasi Anda membutuhkan pemrosesan Asynchronous dan tingkat keandalan dan keamanan terjamin. Sisanya tidak memiliki sistem perpesanan standar dan mengharapkan klien untuk mengatasi kegagalan komunikasi dengan mencoba lagi.
  • Jika keamanan merupakan perhatian utama dan sumber daya tidak terbatas maka kita harus menggunakan layanan web SOAP. Seperti jika kita membuat layanan web untuk gateway pembayaran, pekerjaan terkait keuangan dan telekomunikasi maka kita harus pergi dengan SOAP karena keamanan yang tinggi di sini diperlukan.

enter image description here

source1
sumber2


81
2017-12-08 23:38



Jawaban lain telah memberikan perbedaan yang luas dan menjelaskan banyak hal secara rinci. Jadi saya akan menjauh dari jenis jawaban itu dan bertanya apakah Anda masih bingung, jika demikian maka Anda mungkin ingin melihat analogi sederhana ini. enter image description here


60
2018-06-23 05:19



Keputusan antara keduanya akan menjadi pilihan pertama Anda dalam mendesain layanan web, jadi penting untuk memahami pro dan kontra dari keduanya. Juga penting, dalam perdebatan sengit antara kedua filsafat, untuk memisahkan realitas dari retorika.

REST fundamental

  • Segala sesuatu di REST dianggap sebagai sumber daya.
  • Setiap sumber daya diidentifikasi oleh URI.
  • Menggunakan antarmuka yang seragam. Sumber daya ditangani menggunakan operasi POST, GET, PUT, DELETE yang mirip dengan operasi Create, Read, Update, dan Delete (CRUD).
  • Menjadi tanpa kewarganegaraan. Setiap permintaan adalah permintaan independen. Setiap permintaan dari klien ke server harus berisi semua informasi yang diperlukan untuk memahami permintaan tersebut.
  • Komunikasi dilakukan melalui representasi. Misalnya, XML, JSON, Layanan Web RESTful. Layanan web yang tenang didasarkan pada metode HTTP dan konsep REST. Layanan web yang TEPAT biasanya mendefinisikan URI dasar untuk layanan; jenis MIME yang didukung (XML, teks, JSON, ditentukan pengguna, ...) dan rangkaian operasi (POST, GET, PUT, DELETE) yang didukung.

SOAP fundamental

  • WSDL mendefinisikan kontrak antara klien dan layanan dan bersifat statis menurut sifatnya.
  • SOAP membangun protokol berbasis XML di atas HTTP atau terkadang TCP / IP.
  • SOAP menjelaskan fungsi dan jenis data.
  • SOAP adalah penerus XML-RPC dan sangat mirip, tetapi menggambarkan cara standar untuk berkomunikasi.
  • Beberapa bahasa pemrograman memiliki dukungan asli untuk SOAP, Anda biasanya memberinya URL layanan web, dan Anda dapat memanggil fungsi layanan webnya tanpa perlu kode khusus.
  • Data biner yang dikirim harus dikodekan terlebih dahulu ke dalam format seperti base64 yang dienkode.
  • Memiliki beberapa protokol dan teknologi yang berkaitan dengannya: WSDL, XSD, SOAP, WS-Addressing.

SOAP vs REST?

Salah satu manfaat utama SOAP adalah Anda memiliki deskripsi layanan WSDL. Anda dapat cukup banyak menemukan layanan secara otomatis dan menghasilkan proxy klien yang bisa digunakan dari deskripsi layanan (menghasilkan panggilan layanan, tipe data yang diperlukan untuk metode dan sebagainya). Perhatikan bahwa dengan versi 2.0, WSDL mendukung semua kata kerja HTTP dan dapat digunakan untuk mendokumentasikan layanan RESTful juga, tetapi ada alternatif yang kurang verbose dalam WADL (Bahasa Deskripsi Aplikasi Web) untuk tujuan itu.

Dengan layanan RESTful, keamanan pesan disediakan oleh protokol transport (HTTPS) dan hanya point-to-point. Tidak memiliki sistem perpesanan standar dan mengharapkan klien untuk mengatasi kegagalan komunikasi dengan mencoba lagi. SOAP telah berhasil / coba lagi membangun logika dan menyediakan keandalan end-to-end bahkan melalui perantara SOAP.

Salah satu manfaat utama dari RESTful API adalah bahwa ia fleksibel untuk representasi data, misalnya, Anda dapat membuat serial data Anda dalam format XML atau JSON. API RESTful lebih bersih atau lebih mudah dimengerti karena mereka menambahkan elemen menggunakan URI standar dan memberi arti penting untuk kata kerja HTTP yang digunakan (yaitu, GET, POST, PUT, dan DELETE).

Layanan RESTful juga ringan, yaitu mereka tidak memiliki banyak markup XML tambahan. Untuk memohon API RESTful yang Anda butuhkan hanyalah peramban atau tumpukan HTTP dan hampir semua perangkat atau mesin yang terhubung ke jaringan memilikinya.

Keuntungan REST

  • Karena REST menggunakan HTTP standar, itu jauh lebih sederhana dalam segala hal. Membuat klien, mengembangkan API, dokumentasi jauh lebih mudah dipahami, dan tidak banyak hal yang REST tidak lakukan lebih mudah / lebih baik daripada SOAP.
  • REST memungkinkan banyak format data berbeda sedangkan SOAP hanya mengizinkan XML. Meskipun ini mungkin tampak seperti itu menambah kompleksitas untuk REST karena Anda perlu menangani berbagai format, menurut pengalaman saya, itu sudah cukup bermanfaat. JSON biasanya lebih cocok untuk data dan mem-parsing lebih cepat. REST memungkinkan dukungan yang lebih baik untuk klien browser karena dukungannya untuk JSON.
  • REST memiliki kinerja dan skalabilitas yang lebih baik. Bacaan REST dapat di-cache; Pembacaan berbasis SOAP tidak dapat di-cache.
  • Tidak ada alat mahal yang memerlukan interaksi dengan layanan Web
  • Kurva belajar yang lebih kecil
  • Efisien (SOAP menggunakan XML untuk semua pesan, REST dapat menggunakan format pesan yang lebih kecil)
  • Cepat (tidak memerlukan pemrosesan ekstensif)
  • Lebih dekat dengan teknologi Web lainnya dalam filosofi desain

Keuntungan dari SOAP

  • WS-Security: Sementara SOAP mendukung SSL (seperti REST), SOAP juga mendukung WS-Security yang menambahkan beberapa fitur keamanan perusahaan. Mendukung identitas melalui perantara, bukan hanya point to point (SSL). Ini juga menyediakan implementasi standar integritas data dan privasi data. Dengan menyebutnya "Perusahaan" tidak berarti itu lebih aman, itu hanya mendukung beberapa alat keamanan yang tidak diperlukan oleh layanan internet khas, pada kenyataannya, mereka hanya diperlukan dalam beberapa skenario "perusahaan".
  • WS-AtomicTransaction: Perlu ACID Transaksi melalui layanan, Anda akan memerlukan SOAP. Meskipun REST mendukung transaksi, itu tidak komprehensif dan tidak sesuai dengan ACID. Untungnya, transaksi ACID hampir tidak pernah masuk akal melalui internet. REST dibatasi oleh HTTP itu sendiri yang tidak dapat menyediakan komitmen dua fase di seluruh sumber daya transaksional terdistribusi, tetapi SOAP dapat. Aplikasi internet tidak memerlukan tingkat keandalan transaksional ini, terkadang aplikasi perusahaan.
  • WS-ReliableMessaging: Sisanya tidak memiliki sistem perpesanan standar dan mengharapkan klien untuk mengatasi kegagalan komunikasi dengan mencoba lagi. SOAP telah berhasil / coba lagi membangun logika dan menyediakan keandalan end-to-end bahkan melalui perantara SOAP.
  • Bahasa, platform, dan transportasi independen (REST mengharuskan penggunaan HTTP)
  • Bekerja dengan baik di lingkungan perusahaan terdistribusi (REST mengasumsikan komunikasi langsung point-to-point)
  • Standar
  • Menyediakan perpanjangan pra-membangun signifikan dalam bentuk standar WS
  • Penanganan kesalahan built-in
  • Otomatisasi bila digunakan dengan produk bahasa tertentu

Di mana menggunakan REST 

area tempat REST berfungsi dengan baik adalah:

  • Bandwidth dan sumber daya terbatas: ingat struktur kembalian benar-benar dalam format apa pun (pengembang ditentukan). Plus, browser apa pun dapat digunakan karena pendekatan REST menggunakan kata kerja standar GET, PUT, POST, dan DELETE. Sekali lagi, ingatlah bahwa REST juga dapat menggunakan objek XMLHttpRequest yang paling didukung browser modern saat ini, yang menambahkan bonus AJAX.
  • operasi tanpa negara: jika operasi perlu dilanjutkan, maka REST bukanlah pendekatan terbaik dan SOAP mungkin lebih cocok. Namun, jika Anda memerlukan operasi CRUD (Create, Read, Update, dan Delete) tanpa status negara, maka REST adalah itu.
  • Situasi caching: jika informasi dapat di-cache karena operasi stateless dari pendekatan REST, ini sempurna.

Di mana menggunakan SOAP

area tempat SOAP berfungsi sebagai solusi hebat:

  • Pemrosesan dan permintaan asinkron: jika aplikasi Anda membutuhkan tingkat keandalan dan keamanan yang terjamin, SOAP 1.2 menawarkan standar tambahan untuk memastikan jenis operasi ini. Hal-hal seperti WSRM - Perpesanan WS-Handal.
  • Kontrak formal: jika kedua belah pihak (penyedia dan konsumen) harus menyetujui format pertukaran maka SOAP 1.2 memberikan spesifikasi yang kaku untuk jenis interaksi ini.
  • Operasi yang sah: jika aplikasi membutuhkan informasi kontekstual dan manajemen negara percakapan maka SOAP 1.2 memiliki spesifikasi tambahan dalam struktur WS untuk mendukung hal-hal tersebut (Keamanan, Transaksi, Koordinasi, dll.). Relatif, pendekatan REST akan membuat pengembang membangun pipa saluran khusus ini.

43
2018-04-21 11:12



Perbedaan antara Istirahat dan Sabun

SABUN MANDI

  1. SOAP adalah protokol.
  2. SOAP adalah singkatan dari Simple Object Access Protocol.
  3. SOAP tidak dapat menggunakan REST karena ini adalah protokol.
  4. SOAP menggunakan antarmuka layanan untuk mengekspos logika bisnis.
  5. SOAP mendefinisikan standar yang harus diikuti secara ketat.
  6. SOAP membutuhkan lebih banyak bandwidth dan sumber daya daripada REST.
  7. SOAP mendefinisikan keamanannya sendiri.
  8. SOAP hanya mengizinkan format data XML.
  9. SOAP kurang disukai daripada REST.

BERISTIRAHAT

  1. REST adalah gaya arsitektur.
  2. REST adalah singkatan dari Representational State Transfer.
  3. REST dapat menggunakan layanan web SOAP karena ini adalah konsep dan dapat menggunakan protokol apa pun seperti HTTP, SOAP.
  4. REST menggunakan URI untuk mengekspos logika bisnis.
  5. REST tidak mendefinisikan terlalu banyak standar seperti SOAP.
  6. REST memerlukan lebih sedikit bandwidth dan sumber daya daripada SOAP.
  7. Layanan web RESTful mewarisi langkah-langkah keamanan dari transportasi yang mendasarinya.
  8. REST memungkinkan format data yang berbeda seperti teks Biasa, HTML, XML, JSON dll.
  9. REST lebih disukai daripada SOAP.

Untuk lebih jelasnya silakan lihat sini


29
2018-03-21 12:47