Pro dan Kontra REST vs WSDL


108

Terkait:

Mengapa seseorang menggunakan REST daripada layanan Web?

Ketika memutuskan apakah akan mengimplementasikan layanan web menggunakan SOAP atau REST (maksud saya HTTP / XML dengan cara yang tenang) apa yang harus saya waspadai dan apa yang harus saya pikirkan? Saya berasumsi bahwa ini bukan satu ukuran yang cocok untuk semua, jadi bagaimana saya memilih mana yang akan digunakan.


Pertanyaan ini mungkin memiliki beberapa jawaban yang berguna juga: stackoverflow.com/questions/90451/…
Rob Hruska

2
Itu tergantung pada konteksnya, baik SOAP dan REST memiliki tempatnya. Anda biasanya tidak melihat Hi-SOAP dan lo-SOAP seperti Anda mendengar tentang REST. Alasannya karena ada spesifikasi, dan apakah Anda mengikutinya atau tidak. SOAP menemukan itu digunakan di pusat data di mana Anda memerlukan interoperabilitas antara server yang berbeda yang tidak dapat berkomunikasi secara langsung dan kinerja merupakan faktor penting. Dalam kasus tersebut, sebaiknya lakukan SOAP melalui TCP. SOAP dirancang sebagai transportasi independen, jadi pada dasarnya Anda harus dapat menggunakannya melalui TCP, MSMQ, dll., REST hanya berurusan dengan HTTP.
Srikar Doddi

CodeToGlory benar. Faktanya, WCF Microsoft dirancang khusus untuk membuat SOAP melalui media transportasi semudah nilai dalam file konfigurasi.
Travis Heseman

Kemungkinan duplikat SOAP vs REST (perbedaan)
Hedeshy

Jawaban:


111

Kedua protokol tersebut memiliki kegunaan yang sangat berbeda di dunia nyata.

SOAP (menggunakan WSDL) adalah standar XML kelas berat yang berpusat di sekitar penyampaian dokumen. Keuntungannya adalah permintaan dan tanggapan Anda bisa terstruktur dengan sangat baik, dan bahkan dapat menggunakan DTD. Kelemahannya adalah XML, dan sangat bertele-tele. Namun, ini bagus jika dua pihak perlu memiliki kontrak yang ketat (katakanlah untuk komunikasi antar bank). SOAP juga memungkinkan Anda melapisi hal-hal seperti WS-Security pada dokumen Anda. SOAP umumnya bersifat transport-agnostik, artinya Anda tidak perlu menggunakan HTTP.

REST sangat ringan, dan bergantung pada standar HTTP untuk melakukan pekerjaannya. Sangat bagus untuk mendapatkan layanan web yang berguna dan berjalan dengan cepat. Jika Anda tidak memerlukan definisi API yang ketat, inilah caranya. Sebagian besar layanan web termasuk dalam kategori ini. Anda dapat membuat versi API Anda sehingga pembaruan pada API tidak merusaknya untuk orang yang menggunakan versi lama (selama mereka menentukan versi). REST pada dasarnya membutuhkan HTTP, dan berformat-agnostik (artinya Anda dapat menggunakan XML, JSON, HTML, apa pun).

Umumnya saya menggunakan REST, karena saya tidak memerlukan fitur WS- * yang mewah. SOAP bagus jika Anda ingin komputer memahami layanan web Anda menggunakan WSDL. Spesifikasi REST umumnya hanya dapat dibaca manusia.


5
@JohnSaunders Mengapa ada amplop jika tidak ada dokumen? Saya tidak berpikir saya mengatakan DTD adalah karakteristik unik dari SOAP. Aku sedang tidak mood untuk berdebat hari ini, maaf. Mungkin membaca ulang komentar untuk jawaban Anda atas pertanyaan ini dari hampir 3 tahun yang lalu. Saya tidak berpikir bahwa kelas berat bukanlah hal yang buruk, terkadang Anda menginginkan Holyfield, tetapi di lain waktu Pacquiao menyelesaikan pekerjaannya. Jangan salah paham, dan tidak ada yang pribadi :)
Kekoa

1
SOAP bekerja dengan antarmuka gaya dokumen atau gaya RPC. Juga, SOAP sama sekali tidak menggunakan DTD, sejauh pengetahuan saya. Dan Anda tidak pernah menghitung "kelas berat". Maaf, saya baru saja melihat jawaban Anda, atau saya telah memberikan suara negatif tiga tahun lalu.
John Saunders

2
@JohnSaunders Tidak masalah semoga harimu menyenangkan!
Kekoa

2
REST, seperti SOAP, tidak bergantung pada protokol. Itu tidak bergantung pada HTTP meskipun paling sering digunakan seperti itu. Saya pikir fakta penting yang sering tidak disebutkan adalah bahwa SOAP vs REST membandingkan protokol standar w3c dengan pola arsitektur pragmatis yang didefinisikan secara longgar.
joelmdev

1
@ jm2 Saya belum pernah melihat sisa digunakan di luar HTTP. Saya akan tertarik untuk melihat bagaimana verba GET / POST / PUT / DELETE / etc. bekerja dalam "protokol" istirahat tanpa HTTP. Tautan?
Kekoa

33

Tautan berikut memberikan informasi berguna tentang WSDL vs REST termasuk Pro dan Kontra

Beberapa poin penting adalah itu

1) SOAP dirancang untuk lingkungan komputasi terdistribusi dimana REST dirancang untuk lingkungan titik ke titik.

2) WADL dapat digunakan untuk menentukan antarmuka untuk layanan REST.

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and -wadl


3
REST dirancang untuk sistem terdistribusi: "[...] Gaya arsitektur Representational State Transfer (REST) ​​untuk sistem hypermedia terdistribusi [...]" (Fielding, 2000) ics.uci.edu/~fielding/pubs/dissertation/ rest_arch_style.htm
Thomas Eizinger

19

Menganggap WSDL (artinya "SOAP") sebagai "heavy-weight". Masalah berat bagaimana? Jika perangkat melakukan semua "pekerjaan berat" untuk Anda, lalu mengapa itu penting?

Saya belum pernah perlu menggunakan REST API yang rumit. Ketika saya melakukannya, saya berharap saya akan menginginkan WSDL, yang dengan senang hati akan diubah oleh alat saya menjadi satu set kelas proxy, jadi saya bisa memanggil apa yang tampaknya menjadi metode. Sebaliknya, saya curiga bahwa untuk menggunakan API berbasis REST yang tidak sepele, akan perlu untuk menulis dengan tangan sejumlah besar kode "ringan".

Bahkan ketika semua sudah selesai, Anda masih akan menerjemahkan dokumentasi yang dapat dibaca manusia ke dalam kode, dengan semua risiko yang menyertainya adalah manusia salah membacanya. Karena WSDL adalah deskripsi layanan yang dapat dibaca mesin, jauh lebih sulit untuk "membacanya dengan salah".


Sekadar catatan: sejak posting ini, saya memiliki kesempatan untuk bekerja dengan layanan REST yang cukup rumit. Saya memang, menginginkan WSDL atau yang setara, dan saya memang, harus menulis banyak kode dengan tangan. Faktanya, sebagian besar waktu pengembangan dihabiskan untuk menghapus duplikasi kode dari semua kode yang memanggil operasi layanan yang berbeda "dengan tangan".


Menurut saya "ringan" adalah tentang kinerja, misalnya memuat istilah penelusuran yang disarankan saat Anda mengetik. Saya seorang pria .NET dan saya sangat menghargai beberapa fitur IDE yang mirip dengan apa yang Anda katakan (kelas proxy yang dibuat secara otomatis) tetapi untuk REST ws. Hal seperti itu ada?
Romias

1
Contoh yang Anda sarankan adalah layanan REST sederhana, dan mungkin sulit untuk "salah membaca". Juga, siapa pun yang merasa bahwa kinerja SOAP lebih buruk perlu mendukungnya dengan angka. Saya tidak memiliki kesan bahwa itulah yang dibicarakan oleh fans REST ketika mereka mengatakan "heavy-weight".
John Saunders

3
Bobot berat tidak menghina, maksud saya SOAP memberi Anda banyak hal, dan hadir dengan sedikit kinerja dan harga kompleksitas. Dalam tinju, petinju kelas berat kemungkinan besar dapat melakukan lebih banyak kerusakan daripada yang ringan, tetapi petinju ringan dapat menyelesaikan pekerjaan pada saat kelas berat tidak diperlukan. Selain itu, "hal-hal" tambahan seperti WS-Security, atau Transactions, memperkenalkan kerumitan ekstra yang tidak dimiliki REST.
Kekoa

3
"dukung itu dengan angka" - flamebait klasik. Saya penggemar keduanya, tapi tidak satu pun yang cocok untuk semua.
Kekoa

4
@kekoav: Saya menanggapi Romias yang mengatakan dia pikir "ringan" adalah tentang kinerja. Saya merasa itu harus didukung oleh siapa saja yang merasa seperti itu. Juga, sekali lagi, saya tidak akan mengasumsikan kinerja yang lebih baik tanpa mengukurnya, dan saya tidak akan mengukur, misalnya, transaksi vs. tidak ada transaksi, atau WS-Security versus HTTPS. Bukan umpan api untuk menyarankan pernyataan diverifikasi.
John Saunders

15

Ini mungkin benar-benar milik sebagai komentar di beberapa posting di atas, tetapi saya belum memiliki perwakilan untuk melakukannya, jadi begini.

Saya pikir menarik bahwa banyak pro dan kontra yang sering dikutip untuk SOAP dan REST memiliki (IMO) sangat sedikit hubungannya dengan nilai atau batasan aktual dari kedua teknologi tersebut. Mungkin pro yang paling banyak dikutip untuk REST adalah "ringan" atau cenderung lebih "mudah dibaca manusia". Pada satu tingkat ini memang benar, REST memang memiliki penghalang yang lebih rendah untuk masuk - ada struktur yang kurang dibutuhkan daripada SOAP (meskipun saya setuju dengan mereka yang mengatakan bahwa perkakas yang baik sebagian besar adalah jawabannya di sini - terlalu buruk banyak perkakas SOAP adalah cukup mengerikan).

Namun, di luar biaya masuk awal, saya pikir kesan REST berasal dari kombinasi bentuk URL permintaan dan kompleksitas data yang dipertukarkan oleh sebagian besar layanan REST. REST cenderung mendorong URL permintaan yang lebih sederhana dan lebih dapat dibaca manusia dan datanya cenderung lebih mudah dicerna juga. Namun sejauh mana ini melekat pada REST dan sejauh mana mereka hanya kebetulan. Struktur URL yang lebih sederhana adalah hasil langsung dari arsitektur - tetapi bisa juga diterapkan dengan baik ke layanan berbasis SOAP. Data yang lebih mudah dicerna kemungkinan besar disebabkan oleh kurangnya struktur yang ditentukan. Ini berarti Anda sebaiknya menjaga format data Anda tetap sederhana atau Anda akan melakukan banyak pekerjaan. Jadi di sini struktur tambahan SOAP,

Jadi untuk digunakan dalam pertukaran data terstruktur antara sistem komputer, saya tidak yakin bahwa REST secara inheren lebih baik daripada SOAP (atau sebaliknya), mereka hanya berbeda. Saya pikir perbandingan REST vs SOAP di atas dengan pengetikan dinamis vs statis adalah yang bagus. Di mana bahasa dyanmic cenderung mengalami masalah dalam pemeliharaan jangka panjang dan pemeliharaan sistem (dan dalam jangka panjang saya tidak berbicara satu atau 2 tahun, saya berbicara 5 atau 10). Akan menarik untuk melihat apakah REST mengalami tantangan yang sama dari waktu ke waktu. Saya cenderung berpikir itu akan terjadi sehingga jika saya membangun sistem pemrosesan informasi terdistribusi, saya akan tertarik pada SOAP sebagai mekanisme komunikasi (juga karena pelapisan protokol pengiriman dan aplikasi serta fleksibilitas yang diberikannya seperti yang telah disebutkan di atas).

Di tempat lain, REST tampaknya lebih cocok. AJAX antara klien dan servernya (terlepas dari payload) adalah salah satu contoh utama. Saya tidak terlalu peduli dengan umur panjang jenis koneksi ini dan kemudahan penggunaan dan fleksibilitas sangat rendah. Demikian pula jika saya membutuhkan akses cepat ke beberapa layanan eksternal dan saya tidak berpikir saya akan peduli tentang pemeliharaan interaksi dari waktu ke waktu (sekali lagi saya berasumsi di sinilah REST akan berakhir dengan biaya lebih banyak, satu cara atau lainnya), maka saya dapat memilih REST supaya saya bisa masuk dan keluar dengan cepat.

Bagaimanapun, keduanya adalah teknologi yang layak dan tergantung pada pengorbanan apa yang ingin Anda buat untuk aplikasi tertentu, mereka dapat melayani Anda dengan baik (atau buruk).


5

REST bukanlah protokol; Itu gaya arsitektur. Atau paradigma jika Anda mau. Itu berarti bahwa SOAP jauh lebih longgar. Untuk CRUD dasar, Anda dapat mengandalkan protokol standar seperti Atompub, tetapi untuk sebagian besar layanan, Anda akan memiliki lebih banyak perintah daripada hanya itu.

Sebagai konsumen, SOAP bisa menjadi berkah atau kutukan, tergantung dari dukungan bahasanya. Karena SOAP sangat dimodelkan pada sistem yang diketik dengan ketat, SOAP bekerja paling baik dengan bahasa yang diketik secara statis. Untuk bahasa yang dinamis, ini dapat dengan mudah menjadi kaku dan tidak berguna. Selain itu, dukungan pustaka klien tidak begitu bagus di luar Java dan .NET


Apakah ada alasan yang valid untuk dukungan alat yang buruk di luar Java dan .NET? Apakah ada sesuatu yang hilang dari file WSDL yang akan mencegah, katakanlah, proxy Ruby dibuat?
John Saunders

Secara teknis tidak, tetapi seseorang harus menerapkannya, dan Baik Sun (maaf, Oracle) atau Microsoft akan membayar siapa pun untuk mengimplementasikan pustaka klien di Ruby. Protokol SOAP cukup kompleks. Tambahkan fakta bahwa semua kompleksitas ada dalam sistem tipe, yang hanya sampah dari perspektif bahasa dinamis. Jadi Anda dapat mengatakan bahwa SOAP memaksa sistem tipe statis pada bahasa dinamis. REST adalah sebaliknya.
troelskn

4

Bagi saya, kita harus berhati-hati saat menggunakan kata layanan web. Kita harus selalu menentukan apakah kita berbicara tentang layanan web SOAP, layanan web REST atau jenis layanan web lainnya karena kita berbicara tentang hal-hal yang berbeda di sini dan orang-orang tidak mengerti lagi jika kita menamai semuanya layanan web.

Pada dasarnya layanan web SOAP sudah sangat mapan selama bertahun-tahun dan mereka mengikuti spesifikasi ketat yang menjelaskan bagaimana berkomunikasi dengan mereka berdasarkan spesifikasi SOAP. Sekarang layanan web REST sedikit lebih baru dan pada dasarnya terlihat lebih sederhana karena mereka tidak menggunakan protokol komunikasi apa pun. Pada dasarnya apa yang Anda kirim dan terima ketika Anda menggunakan layanan web REST adalah XML biasa. Orang-orang menyukainya karena mereka dapat mengurai xml seperti yang mereka inginkan tanpa harus berurusan dengan protokol komunikasi yang lebih canggih seperti SOAP.

Bagi saya, layanan REST hampir seperti jika Anda membuat servlet daripada layanan web SOAP. Servlet mendapatkan data masuk dan mengembalikan data keluar. Format datanya berbasis xml. Kita juga bisa membayangkan menggunakan sesuatu selain xml jika kita mau. Misalnya tag dapat digunakan sebagai pengganti xml dan itu tidak akan REST lagi tetapi sesuatu yang lain (Bisa lebih ringan dalam hal bobot karena xml pada dasarnya tidak ringan). Apakah kami akan menyebutnya sebagai layanan web? Ya, kami bisa tetapi itu tidak akan mengikuti standar saat ini dan ini adalah masalah utama di sini jika kami mulai memanggil semua layanan web tetapi kami dapat melakukannya dengan cara yang kami inginkan maka kami kehilangan sisi interoperabilitas dari hal-hal tersebut. Artinya format data yang dipertukarkan dengan web service sudah tidak terstandarisasi lagi.

Apa yang tidak disukai orang dengan SOAP adalah mereka kesulitan untuk memahaminya dan mereka tidak dapat membuat kueri secara manual. Komputer dapat melakukannya dengan sangat baik, jadi di sinilah kita perlu memperjelas: apakah kueri dan respons layanan web seharusnya digunakan secara langsung oleh pengguna akhir atau apakah kami setuju bahwa layanan web berada di bawah API yang disebut oleh sistem komputer berdasarkan beberapa yang dinormalisasi standar?


1
Itu tidak akan menjadi REST lagi?
Steven Shaw

3

SABUN MANDI : Dapat diangkut melalui SMTP juga, artinya kita dapat menjalankan layanan menggunakan format teks sederhana Email juga

Diperlukan framework / engine tambahan pada mesin konsumen web service untuk mengubah pesan SOAP ke struktur objek masing-masing dalam berbagai bahasa.

BERISTIRAHAT : Sekarang WSDL2.0 mendukung untuk menjelaskan layanan web REST juga

Dapat kami gunakan ketika Anda ingin menjadikan layanan Anda ringan, misalnya menelepon dari perangkat seluler seperti ponsel, pda dll ...


Terima kasih telah mengungkit hal ini, @Jenith. Sepertinya tidak ada yang mau membahas ini. WSDL ada hubungannya dengan deskripsi. REST adalah sebuah paradigma. Untuk yang lainnya: silakan lihat Pendahuluan di ibm.com/developerworks/webservices/library/ws-restwsdl . Pertanyaan asli, dengan demikian (mempertimbangkan tanggal masuknya), menunjukkan bahwa judul pertanyaan dipilih dengan buruk (kemungkinan besar memiliki WSDL 1.0 dalam pikiran).
Sonny

3

untuk sistem perusahaan di mana sistem Anda terbatas dalam perusahaan Anda, lebih mudah dan tepat untuk menggunakan sabun karena Anda hampir mengendalikan klien. lebih mudah karena ada berbagai alat yang membuat kelas (proxy) dan sepertinya Anda melakukan OOP biasa yang cocok dengan lingkungan java atau .net Anda (yang digunakan sebagian besar perusahaan).

Saya akan menggunakan REST untuk aplikasi yang menghadap internet untuk mengekspos antarmuka (seperti api twitter) karena klien dapat menggunakan javascript atau html atau lainnya di mana pengetikan tidak ketat. REST menjadi lebih liberal lebih masuk akal.

Juga untuk klien yang berhadapan dengan internet (world wide web), lebih mudah untuk mengurai json atau xml yang keluar dari antarmuka istirahat daripada xml murni yang berasal dari antarmuka sabun. sulit untuk menggunakan proxy pada javascript dan javascript tidak secara alami mendukung objek. Jika Anda menggunakan REST dengan javascript, Anda biasanya hanya akan mengurai string json dan Anda tidak aktif. antarmuka yang menghadap internet biasanya sangat sederhana (sehingga sebagian besar waktu penguraiannya sederhana) dan biasanya tidak menuntut konsistensi, itulah sebabnya REST cukup memadai.

Untuk aplikasi perusahaan, menurut saya REST tidak memadai karena transaksi, keamanan, pengetikan yang ketat, skema memainkan peran yang sangat penting dalam pengembangan aplikasi perusahaan, itulah sebabnya SOAP lebih cocok untuk mereka.

Kesimpulan saya adalah bahwa SOAP untuk sistem Perusahaan, REST untuk Internet atau WWW. Anda dapat menggunakannya secara bergantian tetapi Anda mungkin mengalami kesulitan akhirnya tidak menggunakan alat yang tepat untuk pekerjaan itu.

maaf atas bahasa Inggris saya yang buruk.


2

Dalam pertahanan REST, ia mengikuti prinsip HTTP dan addressability misalnya membaca operasi menggunakan GET, update operasi menggunakan POST dll. Saya menemukan ini menjadi pendekatan yang jauh lebih bersih. Buku Oreilly, RESTful Web Services menjelaskan hal ini jauh lebih baik daripada yang saya bisa, jika Anda membacanya, saya pikir Anda lebih suka pendekatan REST


1

Perangkat di sisi klien akan menjadi satu. Dan keakraban dengan layanan SOAP lainnya. Semakin banyak layanan yang menggunakan rute RESTful hari ini, dan pengujian layanan tersebut dapat dilakukan dengan contoh cURL sederhana. Meskipun, tidak terlalu sulit untuk mengimplementasikan kedua metode dan memungkinkan pemanfaatan seluas-luasnya dari klien.

Jika Anda perlu memilih satu, saya sarankan REST, itu lebih mudah.


1

Jawaban sebelumnya mengandung banyak informasi, namun menurut saya ada perbedaan filosofis yang belum dikemukakan. SOAP adalah jawaban untuk "bagaimana kita membuat penerus independen RPC modern, berorientasi objek, platform dan protokol?". REST dikembangkan dari pertanyaan, "bagaimana cara kami mengambil wawasan yang membuat HTTP begitu sukses untuk web, dan menggunakannya untuk komputasi terdistribusi?"

SOAP adalah tentang memberi Anda alat untuk membuat pemrograman terdistribusi terlihat seperti ... pemrograman. REST mencoba menerapkan gaya untuk menyederhanakan antarmuka terdistribusi, sehingga sumber daya terdistribusi dapat merujuk satu sama lain seperti halaman html terdistribusi dapat saling merujuk. Salah satu caranya adalah mencoba (kebanyakan) membatasi operasi untuk "CRUD" pada sumber daya (buat, baca, perbarui, hapus).

REST masih muda - meskipun berorientasi pada layanan yang "dapat dibaca manusia", REST tidak menutup kemungkinan layanan introspeksi, dll. Atau pembuatan proxy otomatis. Namun, ini belum distandarisasi (seperti yang saya tulis). SOAP memberi Anda hal-hal ini, tetapi (IMHO) memberi Anda "hanya" hal-hal ini, sedangkan gaya yang diberlakukan oleh REST sudah mendorong penyebaran layanan web karena kesederhanaannya. Saya sendiri akan mendorong penyedia layanan pemula untuk memilih REST kecuali ada fitur khusus yang disediakan SOAP yang perlu mereka gunakan.

Menurut pendapat saya, jika Anda mengimplementasikan API "greenfield", dan tidak tahu banyak tentang kemungkinan klien, saya akan memilih REST karena gaya yang didorongnya cenderung membantu membuat antarmuka dapat dipahami, dan mudah dikembangkan. Jika Anda tahu banyak tentang klien dan server, dan ada alat SOAP khusus yang akan membuat hidup mudah untuk keduanya, maka saya tidak akan religius tentang REST.


-1: ini sebenarnya tidak menjawab pertanyaan itu. Dikatakan sedikit atau tidak sama sekali tentang "mengapa saya harus memilih salah satu dari yang lain"?
John Saunders

1
Saya berkonsentrasi untuk memberikan informasi yang tidak dimiliki orang lain - tetapi telah menambahkan kesimpulan jika Anda diminta.
mulai

0

Anda dapat dengan mudah mengalihkan komponen web WCF yang memuntahkan WSDL Anda ke penggunaan lain hanya dengan mengubah pengaturan konfigurasi Anda. Anda dapat melewati HTTP dan kemudian juga menamai pipa, tcp, protokol khusus, dll tanpa harus mengubah kode Anda. Saya yakin komponen WCF mungkin juga lebih mudah diatur untuk hal-hal seperti keamanan, panggilan dua arah, transaksi, konkurensi, dll.

REST cukup banyak membatasi Anda ke HTTP (yang baik-baik saja dalam banyak kasus).


0

Saya tahu bahwa diskusi ini adalah yang lama, tetapi setelah membaca semua jawaban dan berkomentar, saya percaya bahwa semua orang melewatkan poin terpenting tentang perbedaan antara 2 sistem: SOAP menggunakan tipe kompleks untuk tidak hanya memberi Anda data, tetapi juga memvalidasi dan menyimpannya dalam penunjukan tipe yang ketat seperti yang telah didefinisikan. WSDL memberi tahu Anda apa format datanya, apa tipe datanya, memungkinkan Anda menambahkan aturan gaya-pola reg-ex, dan menentukan berapa kali sebuah data harus, dan mungkin, diizinkan dalam permintaan / respons . Istirahat di sisi lain tidak memiliki mekanisme ini.

SOAP rumit dan berat karena memungkinkan Anda mengirim data hierarki yang berat dan kompleks. REST adalah teks biasa, dengan asal dan titik akhir yang mengurutkan aturan.

SOAP adalah bisnis independen, karena memiliki semua aturan data yang disematkan dalam dokumen.

Perbedaan antara SOAP dan REST adalah bahwa SOAP adalah skema berorientasi bisnis mandiri. REST adalah dokumen teks.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.