it-swarm-id.com

SOAP atau REST untuk Layanan Web?

Apakah REST pendekatan yang lebih baik untuk melakukan Layanan Web atau SOAP? Atau apakah mereka alat yang berbeda untuk masalah yang berbeda? Atau apakah itu masalah yang bernuansa - yaitu, apakah ada yang sedikit lebih baik di arena tertentu daripada yang lain, dll?

Saya akan sangat menghargai informasi tentang konsep-konsep dan hubungannya dengan alam semesta PHP dan juga aplikasi web modern kelas atas.

380
user13276

Saya membangun salah satu server SOAP pertama, termasuk pembuatan kode dan generasi WSDL, dari spesifikasi asli yang sedang dikembangkan, ketika saya bekerja di Hewlett-Packard. Saya TIDAK merekomendasikan menggunakan SOAP untuk apa pun.

Singkatan "SABUN" adalah bohong. Ini tidak sederhana, tidak berorientasi objek, tidak mendefinisikan aturan akses. Ini, bisa dibilang, Protokol. Ini adalah spec terburuk Don Box, dan itu cukup luar biasa, karena dialah orang yang melakukan "COM".

Tidak ada yang berguna dalam SOAP yang tidak dapat dilakukan dengan REST untuk transportasi, dan JSON, XML, atau bahkan teks biasa untuk representasi data. Untuk keamanan transportasi, Anda dapat menggunakan https. Untuk otentikasi, auth dasar. Untuk sesi, ada cookie. Versi REST akan lebih sederhana, lebih jelas, berjalan lebih cepat, dan menggunakan lebih sedikit bandwidth.

XML-RPC dengan jelas mendefinisikan protokol permintaan, respons, dan kesalahan, dan ada perpustakaan yang bagus untuk sebagian besar bahasa. Namun, XML lebih berat daripada yang Anda butuhkan untuk banyak tugas.

562
mdhughes

REST adalah arsitektur, SOAP adalah protokol.

Itu masalah pertama.

Anda dapat mengirim SOAP amplop dalam aplikasi REST.

SOAP sendiri sebenarnya cukup mendasar dan sederhana, standar WSS- * yang membuatnya sangat kompleks.

Jika konsumen Anda adalah aplikasi lain dan server lain, ada banyak dukungan untuk protokol SOAP hari ini, dan dasar-dasar memindahkan data pada dasarnya adalah klik-mouse pada IDE modern.

Jika konsumen Anda lebih cenderung menjadi klien RIA atau Ajax, Anda mungkin ingin sesuatu yang lebih sederhana daripada SOAP, dan lebih asli untuk klien (terutama JSON).

Paket JSON yang dikirim melalui HTTP tidak harus berupa arsitektur REST, itu hanya pesan ke URL. Semua bisa diterapkan dengan sempurna, tetapi ada komponen kunci untuk idiom REST. Namun mudah untuk membingungkan keduanya. Tetapi hanya karena Anda sedang berbicara permintaan HTTP tidak berarti Anda memiliki arsitektur REST. Anda dapat memiliki aplikasi REST tanpa HTTP sama sekali (ingat, ini jarang terjadi).

Jadi, jika Anda memiliki server dan konsumen yang "nyaman" dengan SOAP, SOAP dan tumpukan WSS dapat melayani Anda dengan baik. Jika Anda melakukan lebih banyak hal ad hoc dan ingin antarmuka yang lebih baik dengan browser web, maka beberapa protokol yang lebih ringan melalui HTTP juga dapat bekerja dengan baik.

198
Will Hartung

REST adalah paradigma yang secara fundamental berbeda dari SOAP. Bacaan yang bagus tentang REST dapat ditemukan di sini: Bagaimana saya menjelaskan REST kepada istri saya .

Jika Anda tidak punya waktu untuk membacanya, inilah versi singkatnya: REST adalah sedikit perubahan paradigma dengan berfokus pada "kata benda", dan menahan jumlah "kata kerja" yang dapat Anda terapkan pada kata benda. Satu-satunya kata kerja yang diizinkan adalah "get", "put", "post" dan "delete". Ini berbeda dari SOAP di mana banyak kata kerja yang berbeda dapat diterapkan ke banyak kata benda yang berbeda (yaitu banyak fungsi yang berbeda).

Untuk REST, empat kata kerja dipetakan ke permintaan HTTP yang sesuai, sementara kata benda diidentifikasi oleh URL. Ini membuat manajemen negara jauh lebih transparan daripada di SOAP, di mana sering tidak jelas status apa yang ada di server dan apa yang ada di klien.

Dalam prakteknya meskipun sebagian besar ini hilang, dan REST biasanya hanya merujuk pada permintaan HTTP sederhana yang mengembalikan hasil dalam JSON , sementara SOAP lebih API kompleks yang berkomunikasi dengan melewati XML. Keduanya memiliki kelebihan dan kekurangan, tetapi saya telah menemukan bahwa dalam pengalaman saya REST biasanya merupakan pilihan yang lebih baik karena Anda jarang membutuhkan fungsionalitas penuh yang Anda dapatkan dari SOAP.

102
toluju

Lowdown cepat untuk pertanyaan 2012:

Area yang REST berfungsi dengan sangat baik adalah:

  • Bandwidth dan sumber daya terbatas. Ingat struktur pengembalian benar-benar dalam format apa pun (ditentukan pengembang). Plus, browser apa pun dapat digunakan karena pendekatan REST menggunakan kata kerja GET, PUT, POST, dan DELETE standar. Sekali lagi, ingat bahwa REST juga dapat menggunakan objek XMLHttpRequest yang didukung sebagian besar browser modern saat ini, yang menambahkan bonus tambahan dari AJAX.

  • Operasi yang benar-benar tanpa kewarganegaraan. Jika suatu operasi perlu dilanjutkan, maka REST bukan pendekatan terbaik dan SOAP mungkin lebih cocok. Namun, jika Anda memerlukan operasi CRUD stateless (Buat, Baca, Perbarui, dan Hapus), maka REST itu.

  • Situasi caching. Jika informasi dapat di-cache karena operasi statelessREST yang benar-benar tanpa kewarganegaraan, ini sempurna. Itu mencakup banyak solusi di tiga di atas.

Jadi mengapa saya bahkan mempertimbangkan SABUN? Sekali lagi, SOAP cukup matang dan terdefinisi dengan baik dan dilengkapi dengan spesifikasi lengkap. Pendekatan REST hanya itu, sebuah pendekatan dan terbuka lebar untuk pengembangan, jadi jika Anda memiliki yang berikut ini maka SOAP adalah solusi yang bagus:

  • Pemrosesan dan pemanggilan tidak sinkron. Jika aplikasi Anda membutuhkan tingkat keandalan dan keamanan yang terjamin maka SOAP 1.2 menawarkan standar tambahan untuk memastikan jenis ini operasi. Hal-hal seperti WSRM - WS-Reliable Messaging.

  • Kontrak formal. Jika kedua belah pihak (penyedia dan konsumen) harus menyetujui format pertukaran maka SOAP 1.2 memberikan spesifikasi kaku untuk jenis interaksi ini.

  • Operasi stateful. Jika aplikasi membutuhkan informasi kontekstual dan manajemen keadaan 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 membuat pipa ledeng kustom ini.

http://www.infoq.com/articles/rest-soap-when-to-use-each

59
PmanAce

SOAP saat ini memiliki keuntungan dari alat yang lebih baik di mana mereka akan menghasilkan banyak kode boilerplate untuk kedua lapisan layanan serta menghasilkan klien dari WSDL yang diberikan.

REST lebih sederhana, dapat lebih mudah untuk mempertahankannya, terletak di jantung arsitektur Web, memungkinkan visibilitas protokol yang lebih baik, dan telah terbukti berskala pada ukuran WWW itu sendiri. Beberapa kerangka kerja di luar sana membantu Anda membangun layanan REST, seperti Ruby di Rails, dan beberapa bahkan membantu Anda dengan menulis klien, seperti Layanan Data ADO.NET. Tetapi untuk sebagian besar, dukungan alat kurang.

44
Mark Cidade

SOAP berguna dari perspektif perkakas karena WSDL sangat mudah dikonsumsi oleh perkakas. Jadi, Anda bisa mendapatkan klien Layanan Web yang dihasilkan untuk Anda dalam bahasa favorit Anda.

REST bermain dengan baik dengan halaman web AJAX'y. Jika Anda membuat permintaan Anda sederhana, Anda dapat membuat panggilan layanan langsung dari JavaScript Anda, dan itu sangat berguna. Cobalah untuk menjauh dari memiliki ruang nama apa pun di XML respons Anda, saya telah melihat browser mencekiknya. Jadi, xsi: type mungkin tidak akan bekerja untuk Anda, tidak ada skema XML yang terlalu rumit.

REST cenderung memiliki kinerja yang lebih baik juga. Persyaratan CPU dari kode yang menghasilkan REST respons cenderung lebih rendah daripada yang ditampilkan oleh SOAP frameworks. Dan, jika Anda memiliki bebek generasi XML yang berjejer di sisi server, Anda dapat mengalirkan XML secara efektif ke klien. Jadi, bayangkan Anda membaca deretan kursor basis data. Saat Anda membaca baris, Anda memformatnya sebagai elemen XML, dan Anda menulisnya langsung ke konsumen layanan. Dengan cara ini, Anda tidak perlu mengumpulkan semua baris basis data dalam memori sebelum mulai menulis output XML Anda - Anda membaca dan menulis pada saat yang sama. Lihatlah ke mesin templating novel atau XSLT untuk membuat streaming bekerja untuk REST.

Di sisi lain, SOAP cenderung dihasilkan oleh layanan yang dihasilkan oleh alat sebagai gumpalan besar dan baru kemudian ditulis. Ini bukan kebenaran absolut, ingatlah, ada cara untuk mendapatkan karakteristik streaming dari SOAP, seperti dengan menggunakan lampiran.

Proses pengambilan keputusan saya adalah sebagai berikut: jika saya ingin layanan saya mudah digunakan oleh konsumen, dan pesan yang saya tulis akan berukuran sedang hingga kecil (10MB atau kurang), dan saya tidak keberatan membakar beberapa CPU tambahan siklus di server, saya pergi dengan SOAP. Jika saya perlu melayani ke AJAX di peramban web, atau saya perlu sesuatu untuk streaming, atau tanggapan saya sangat besar, saya pergi REST.

Akhirnya, ada banyak standar hebat yang dibangun di sekitar SOAP, seperti WS-Security dan mendapatkan Layanan Web yang canggih, yang bisa Anda pasang jika Anda menggunakan alat yang tepat. Hal-hal semacam itu benar-benar membuat perbedaan, dan dapat membantu Anda memenuhi beberapa persyaratan berbulu.

40
Dave Woldrich

Saya tahu ini adalah pertanyaan lama tetapi saya harus mengirimkan jawaban saya - mungkin seseorang akan merasakan manfaatnya. Saya tidak percaya berapa banyak orang merekomendasikan REST lebih dari sabun. Saya hanya dapat berasumsi bahwa orang-orang ini bukan pengembang atau belum pernah benar-benar mengimplementasikan layanan REST dalam ukuran apa pun yang masuk akal. Menerapkan layanan REST membutuhkan LOT lebih lama daripada menerapkan layanan SOAP. Dan pada akhirnya keluar juga lebih berantakan. Inilah alasan saya memilih SOAP 99% dari waktu:

1) Menerapkan layanan REST membutuhkan waktu yang jauh lebih lama daripada menerapkan layanan SOAP. Ada alat untuk semua bahasa/kerangka/platform modern untuk membaca di WSDL dan kelas dan klien proxy keluaran. Menerapkan layanan REST dilakukan dengan tangan dan - dapatkan ini - dengan membaca dokumentasi. Selain itu, saat menerapkan kedua layanan ini, Anda harus membuat "tebakan" tentang apa yang akan kembali ke pipa karena tidak ada skema nyata atau dokumen referensi.

2) Mengapa menulis layanan REST yang mengembalikan XML? Satu-satunya perbedaan adalah bahwa dengan REST Anda tidak tahu jenis yang diwakili oleh setiap elemen/atribut - Anda sendiri yang mengimplementasikannya dan berharap suatu hari suatu string tidak menemukan bidang yang Anda tuju. Pikiran selalu int. SOAP mendefinisikan struktur data menggunakan WSDL jadi ini adalah no-brainer.

3) Saya pernah mendengar keluhan bahwa dengan SOAP Anda memiliki "overhead" dari SOAP Amplop. Di zaman sekarang ini, apakah kita benar-benar perlu khawatir tentang beberapa byte?

4) Saya pernah mendengar argumen bahwa dengan REST Anda bisa memasukkan URL ke browser dan melihat datanya. Tentu, jika layanan REST Anda menggunakan otentikasi sederhana atau tidak. Layanan Netflix, misalnya, menggunakan OAuth yang mengharuskan Anda untuk menandatangani sesuatu dan menyandikan sesuatu sebelum Anda bahkan dapat mengirimkan permintaan Anda.

5) Mengapa kita membutuhkan URL yang "dapat dibaca" untuk setiap sumber daya? Jika kami menggunakan alat untuk mengimplementasikan layanan, apakah kami benar-benar peduli dengan URL yang sebenarnya?

Perlu saya lanjutkan?

29
Josh M.

Sebagian besar aplikasi yang saya tulis adalah server-side C # atau Java, atau aplikasi desktop di WinForms atau WPF. Aplikasi ini cenderung membutuhkan API layanan yang lebih kaya daripada yang dapat disediakan REST. Plus, saya tidak ingin menghabiskan lebih dari beberapa menit membuat klien layanan web saya. Alat generasi klien pemrosesan WSDL memungkinkan saya untuk mengimplementasikan klien saya dan beralih ke menambahkan nilai bisnis.

Sekarang, jika saya menulis layanan web secara eksplisit untuk beberapa panggilan ajax javascript, itu mungkin berada di REST; hanya demi mengetahui teknologi klien dan memanfaatkan JSON. Menurut pendapat saya, API layanan web yang digunakan dari javascript mungkin seharusnya tidak terlalu rumit, karena jenis kompleksitas itu tampaknya lebih baik ditangani di sisi server.

Dengan itu, ada beberapa SOAP klien untuk javascript; Saya tahu jQuery memilikinya. Jadi, SOAP bisa dimanfaatkan dari javascript; hanya saja tidak sebagus layanan REST yang mengembalikan string JSON. Jadi jika saya memiliki layanan web yang saya ingin cukup kompleks sehingga fleksibel untuk sejumlah teknologi dan penggunaan klien, saya akan menggunakan SOAP.

19
Travis Heseman

Saya sarankan Anda pergi dengan REST pertama - jika Anda menggunakan Java lihat JAX-RS dan Jersey implementasi. REST jauh lebih sederhana dan mudah diinterupsi dalam banyak bahasa.

Seperti yang orang lain katakan di utas ini, masalah dengan SOAP adalah kerumitannya ketika spesifikasi WS- * lainnya masuk dan ada masalah interop yang tak terhitung jumlahnya jika Anda menyimpang ke bagian WSDL, XSDs, SOAP yang salah, Mengatasi WS dll.

Cara terbaik untuk menilai debat REST v SOAPadalah dengan melihat di internet - hampir semua pemain besar di ruang web, google, Amazon, ebay, Twitter, dan lain-lain. untuk menggunakan dan lebih suka API tenang daripada SOAP yang.

Pendekatan lain yang bagus untuk menggunakan REST adalah Anda dapat menggunakan kembali banyak kode dan infrastruktur antara aplikasi web dan frontlin REST. misalnya rendering HTML versus XML versus JSON dari sumber daya Anda biasanya cukup mudah dengan kerangka kerja seperti JAX-RS dan tampilan tersirat - plus mudah untuk bekerja dengan sumber daya tenang menggunakan browser web

17
James Strachan

Saya yakin Don Box menciptakan SOAP sebagai lelucon - 'lihat Anda dapat panggil metode RPC melalui web' dan hari ini mengeluh ketika dia menyadari betapa mimpi buruk yang membengkak dari standar web itu telah menjadi :-)

REST baik, sederhana, diterapkan di mana-mana (jadi lebih 'standar' daripada standar) cepat dan mudah. Gunakan REST.

16
gbjbaanb

Saya pikir keduanya memiliki tempat sendiri. Menurutku:

SOAP: Pilihan yang lebih baik untuk integrasi antara sistem warisan/kritis dan sistem layanan web/web, pada lapisan fondasi, tempat WS- * masuk akal (keamanan, kebijakan, dll.).

TENANG: Pilihan yang lebih baik untuk integrasi antara situs web, dengan API publik, pada TOP of layer (LIHAT, yaitu, javascripts menerima panggilan ke URI).

15
irobson

Satu hal yang belum disebutkan adalah bahwa amplop SOAP dapat berisi header dan juga bagian tubuh. Ini memungkinkan Anda menggunakan ekspresif penuh XML untuk mengirim dan menerima informasi band keluar. REST, sejauh yang saya tahu, membatasi Anda ke HTTP Header dan kode hasil.

(otoh, bisakah Anda menggunakan cookie dengan layanan REST untuk mengirim "header" -jenis data band?)

13
John Saunders

Menjawab pertanyaan 2012 yang diperbarui (dengan hadiah kedua), dan meninjau hasil hari ini (jawaban lain).


SABUN, pro dan kontra

Tentang SOAP 1.2, kelebihan dan kekurangan saat membandingkan dengan "REST" ... Ya, sejak 2007 Anda dapat menggambarkan REST layanan web dengan WSDL , dan menggunakan SOAP protokol ... Yaitu, jika Anda bekerja sedikit lebih keras, semua standar W3C dari tumpukan protokol layanan web dapat REST !

Ini adalah titik awal yang baik, karena kita dapat membayangkan skenario di mana semua diskusi filosofis dan metodologis dihindari sementara. Kami dapat membandingkan secara teknis "SOAP-REST" dengan "NON-SOAP-REST" di layanan serupa,

  • SOAP-REST (= "REST-SOAP"): as ditunjukkan oleh L.Mandel , WSDL2 dapat menggambarkan REST layanan web, dan, jika kami mengira XML yang dicontohkan dapat dimasukkan ke dalam SOAP, semua implementasi akan menjadi "SOAP-REST".

  • NON-SOAP-REST : any REST layanan web yang tidak bisa SOAP ... Yaitu, "90%" dari contoh REST yang terkenal. Beberapa tidak menggunakan XML (mis. Khas AJAX REST menggunakan JSON sebagai gantinya), beberapa menggunakan struktur XML lain, tanpa header atau aturan SOAP. PS: untuk menghindari informalitas, kita bisa menduga REST level 2 dalam perbandingan.

Tentu saja, untuk membandingkan secara lebih konseptual, bandingkan "NON-REST-SOAP" dengan "NON-SOAP-REST", sebagai pendekatan pemodelan yang berbeda. Jadi, selesaikan taksonomi layanan web ini:

  • NON-REST-SOAP : any SOAP layanan web yang tidak dapat REST ... Yaitu, "90%" dari contoh SOAP yang terkenal.

  • NON-REST-NEITHER-SOAP : ya, semesta "pemodelan layanan web" terdiri dari hal-hal lain (mis. XML-RPC ).

SABUN dalam kondisi REST

Membandingkan hal-hal yang sebanding: SOAP-REST dengan NON-SOAP-REST .

PROS

Menjelaskan beberapa istilah,

  • Stabilitas kontrak : untuk semua jenis kontrak (sebagai "perjanjian tertulis"),

    • Dengan penggunaan standar : semua tingkat tumpukan W3C saling memenuhi syarat. REST, sebaliknya, bukan W3C atau standar ISO, dan tidak memiliki rincian normal tentang periferal layanan. Jadi, seperti I , @DaveWoldrich (20 suara), @cynicalman (5), @Exitos (0) katakan sebelumnya, dalam konteks di mana DIPERLUKAN UNTUK STANDAR, Anda perlu SABUN.

    • Dengan penggunaan praktik terbaik : "aspek verbose" dari implementasi tumpukan W3C , menerjemahkan perjanjian manusia/hukum/yuridik yang relevan .

  • Robustness : keamanan SOAP struktur dan header. Dengan komunikasi metada (dengan ekspresi penuh XML) dan verifikasi Anda memiliki "polis asuransi" terhadap setiap perubahan atau kebisingan.
    SOAP memiliki "keandalan transaksional (...) menangani kegagalan komunikasi. SOAP memiliki lebih banyak kontrol di sekitar coba lagi logika dan dengan demikian dapat memberikan keandalan dan jaminan layanan ujung ke ujung yang lebih banyak", - E. Terman .

Mengurutkan pro berdasarkan popularitas,

  • Alat yang lebih baik (~ 70 suara): SOAP saat ini memiliki keunggulan alat yang lebih baik, sejak 2007 dan masih 2012, karena ini adalah standar yang didefinisikan dengan baik dan diterima secara luas. Lihat @MarkCidade (27 suara), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9).

  • Pemenuhan standar (25 suara): sebagai I , @DaveWoldrich (20 suara), @cynicalman (5), @Exitos (0) katakan sebelumnya, dalam konteks di mana DIPERLUKAN UNTUK STANDAR, Anda perlu SABUN.

  • Robustness : asuransi SOAP header, @JohnSaunders (8 suara).

Kon

  • Strucuture SOAP lebih kompleks (lebih dari 300 suara): semua jawaban di sini, dan sumber-sumber tentang "SOAP vs REST", menunjukkan tingkat ketidaksukaan terhadap SOAP redundansi dan kompleksitas. Ini adalah konsekuensi alami dari persyaratan untuk verifikasi formal (lihat di bawah), dan untuk ketahanan (lihat di atas). "REST NON-SOAP" (dan XML-RPC, the SOAP originator ) dapat menjadi lebih sederhana dan informal.

  • Pembatasan "hanya XML" adalah hambatan kinerja ketika menggunakan layanan kecil (~ 50 suara): lihat json.org/xml = dan pertanyaan ini , atau yang lain ini . Poin ini ditunjukkan oleh @toluju (41), dan lainnya.
    PS: as JSON bukan standar IETF , tetapi kita dapat mempertimbangkan standar de facto untuk komunitas perangkat lunak web.


Layanan pemodelan dengan SOAP

Sekarang, kita dapat menambahkan SOAP-NON-REST dengan perbandingan NON-SOAP-REST , dan menjelaskan kapan lebih baik menggunakan SOAP :

  • Kebutuhan akan standar dan kontrak yang stabil (lihat bagian "PROS"). PS: lihat khas "kebutuhan B2B untuk standar" dijelaskan oleh @saille .

  • Kebutuhan alat (lihat bagian "PROS"). PS: standar , dan keberadaan verifikasi formal (lihat di bawah), adalah masalah penting untuk otomatisasi alat.

  • Pemrosesan berat paralel (lihat bagian "Konteks/Yayasan" di bawah): dengan proses yang lebih besar dan/atau lebih lambat, tidak masalah dengan kompleksitas SOAP yang sedikit lebih banyak, keandalan dan stabilitas adalah yang terbaik investasi.

  • Membutuhkan keamanan lebih : ketika lebih dari HTTPS diperlukan, dan Anda benar-benar membutuhkan fitur tambahan untuk perlindungan, SOAP adalah pilihan yang lebih baik ( lihat @ Bel , 32 suara). "Mengirim pesan di sepanjang jalur yang lebih rumit daripada permintaan/tanggapan atau melalui transportasi yang tidak melibatkan HTTP", S. Seely . XML adalah masalah inti, menawarkan standar untuk Enkripsi XML , Tanda Tangan XML , dan Kanonisasi XML , dan, hanya dengan SOAP Anda dapat menanamkan mekanisme ini ke dalam pesan dengan standar yang diterima dengan baik sebagai WS-Security .

  • Perlu lebih banyak fleksibilitas (pembatasan kurang): SOAP tidak perlu korespondensi yang tepat dengan URI; tidak perlu membatasi ke HTTP; tidak perlu membatasi hingga 4 kata kerja. Seperti yang dikatakan @TravisHeseman (9 suara), jika Anda menginginkan sesuatu "fleksibel untuk sejumlah teknologi dan penggunaan klien", gunakan SOAP.
    PS: ingat bahwa XML lebih universal/ekspresif daripada JSON (et al).

  • Kebutuhan untuk verifikasi formal: penting untuk memahami bahwa tumpukan W3C menggunakan metode formal , dan REST lebih informal. WSDL Anda (a bahasa formal ) deskripsi layanan adalah spesifikasi formal dari antarmuka layanan web Anda, dan SOAP adalah protokol yang kuat yang menerima semua kemungkinan WSDL resep.

KONTEKS

Historis

Untuk menilai tren diperlukan perspektif historis. Untuk mata pelajaran ini, perspektif 10 atau 15 tahun ...

Sebelum standardisasi W3C, ada beberapa anarki. Sulit untuk mengimplementasikan layanan interoperable dengan kerangka kerja yang berbeda, dan lebih sulit, mahal, dan memakan waktu untuk mengimplementasikan sesuatu yang interoperable antara perusahaan. Standar W3C stack telah menjadi cahaya, utara untuk interoperasi set layanan web yang kompleks.

Untuk tugas sehari-hari, seperti mengimplementasikan AJAX, SOAP sangat berat ... Jadi, kebutuhan akan pendekatan sederhana perlu memilih kerangka teori baru ... Dan "pemain perangkat lunak Web" yang besar , karena Google, Amazon, Yahoo, dkk, memilih alternatif terbaik, yaitu pendekatan REST. Apakah dalam konteks ini bahwa REST konsep tiba sebagai "kerangka kerja bersaing", dan, hari ini (2012), alternatif ini adalah standar de facto untuk programmer.

Yayasan

Dalam konteks Parallel Computing layanan web menyediakan subtugas paralel; dan protokol, seperti SOAP, memastikan sinkronisasi dan komunikasi yang baik. Bukan "tugas apa pun": layanan web dapat diklasifikasikan sebagai
paralelisme kasar dan memalukan .

Ketika tugas bertambah besar, itu menjadi "debat kompleksitas" yang kurang signifikan, dan menjadi lebih relevan dengan kekuatan komunikasi dan soliditas kontrak.

10
Peter Krauss

Jangan mengabaikan XML-RPC. Jika Anda hanya mencari solusi yang ringan maka ada banyak yang bisa dikatakan untuk protokol yang dapat didefinisikan dalam beberapa halaman teks dan diimplementasikan dalam jumlah kode yang minimal. XML-RPC telah ada selama bertahun-tahun tetapi keluar dari mode untuk sementara waktu - tetapi daya tarik minimalis tampaknya memberikannya sesuatu kebangkitan akhir-akhir ini.

10
Cruachan

Itu bernuansa.

Jika Anda perlu memiliki antarmuka sistem lain dengan layanan Anda, maka banyak klien akan lebih senang dengan SOAP, karena lapisan "verifikasi" yang Anda miliki dengan kontrak, WSDL, dan standar SOAP.

Untuk sistem sehari-hari yang memanggil sistem, saya pikir SOAP adalah banyak overhead yang tidak perlu saat melakukan panggilan HTML sederhana.

9
cynicalman

Saya melihat hal yang sama, dan saya pikir, mereka adalah alat yang berbeda untuk masalah yang berbeda.

Standar Simple Object Access Protocol (SOAP) bahasa XML yang mendefinisikan arsitektur pesan dan format pesan, digunakan oleh layanan Web yang berisi deskripsi operasi. WSDL adalah bahasa berbasis XML untuk menggambarkan layanan Web dan cara mengaksesnya. akan berjalan pada SMTP, HTTP, FTP dll. Memerlukan dukungan middleware, mekanisme yang terdefinisi dengan baik untuk mendefinisikan layanan seperti WSDL + XSD, Kebijakan WS SOAP akan mengembalikan data berbasis XML SOAP memberikan standar untuk keamanan dan keandalan

Layanan web State Representative Transfer (RESTful). mereka adalah Layanan Web generasi kedua. Layanan web yang tenang, berkomunikasi melalui HTTP daripada layanan berbasis SOAP dan tidak memerlukan pesan XML atau definisi layanan-API WSDL. untuk REST tidak perlu middleware, hanya dukungan HTTP yang diperlukan. Standar WADL, REST dapat mengembalikan XML, teks biasa, JSON, HTML dll.

Lebih mudah bagi banyak jenis klien untuk mengkonsumsi layanan web RESTful sementara memungkinkan sisi server untuk berkembang dan berkembang. Klien dapat memilih untuk mengkonsumsi beberapa atau semua aspek layanan dan menumbuhkannya dengan layanan berbasis web lainnya.

  1. REST menggunakan HTTP standar sehingga sederhana untuk membuat klien, mengembangkan API
  2. REST memungkinkan banyak format data yang berbeda seperti XML, teks biasa, JSON, HTML di mana SOAP hanya mengizinkan XML.
  3. REST memiliki kinerja dan skalabilitas yang lebih baik.
  4. Istirahat dan bisa di-cache dan SOAP tidak bisa
  5. Penanganan kesalahan internal di mana SOAP tidak memiliki penanganan kesalahan
  6. REST sangat berguna PDA dan perangkat seluler lainnya.

REST adalah layanan yang mudah diintegrasikan dengan situs web yang ada.

SOAP memiliki seperangkat protokol, yang menyediakan standar untuk keamanan dan keandalan, antara lain, dan beroperasi dengan klien dan server yang sesuai dengan WS lainnya. SOAP Layanan web (seperti JAX-WS) berguna dalam menangani pemrosesan dan pemanggilan asinkron.

Untuk API Kompleks SOAP akan lebih bermanfaat.

9
kapil das

REST adalah arsitektur yang ditemukan oleh Roy Fielding dan dijelaskan dalam disertasinya Gaya Arsitektur dan Desain Arsitektur Perangkat Lunak Berbasis Jaringan . Roy juga penulis utama HTTP - protokol yang mendefinisikan transfer dokumen melalui World Wide Web. HTTP adalah protokol yang tenang. Ketika pengembang berbicara tentang "menggunakan REST layanan Web" mungkin lebih akurat untuk mengatakan "menggunakan HTTP."

SOAP adalah protokol berbasis XML yang terowongan di dalam permintaan/respons HTTP, jadi bahkan jika Anda menggunakan SOAP, Anda juga menggunakan REST. Ada beberapa perdebatan mengenai apakah SOAP menambahkan fungsionalitas signifikan ke HTTP dasar.

Sebelum membuat layanan Web, saya akan merekomendasikan mempelajari HTTP. Kemungkinannya adalah persyaratan Anda dapat diimplementasikan dengan fungsionalitas yang sudah ditentukan dalam spesifikasi, sehingga protokol lain tidak diperlukan.

8
Chris Broski

Saya melihat masalah yang sama. Menurut saya itu sebenarnya REST cepat dan mudah dan bagus untuk panggilan dan respons yang ringan dan bagus untuk debugging (apa yang bisa lebih baik daripada memompa URL ke browser dan melihat responsnya).

Namun di mana REST tampaknya jatuh berkaitan dengan fakta bahwa itu bukan standar (meskipun terdiri dari standar). Sebagian besar perpustakaan pemrograman memiliki cara memeriksa WSDL untuk secara otomatis menghasilkan kode klien yang diperlukan untuk mengkonsumsi layanan berbasis SOAP. Sejauh ini, layanan web berbasis REST tampaknya merupakan pendekatan yang lebih adhoc dalam menulis antarmuka agar sesuai dengan panggilan yang dimungkinkan. Membuat permintaan http manual lalu mem-parsing respons. Ini sendiri bisa berbahaya.

Keindahan SOAP adalah bahwa sekali WSDL dikeluarkan, maka bisnis 'dapat menyusun logika mereka di luar yang mengatur kontrak perubahan apa pun pada antarmuka akan mengubah wsdl. Tidak ada ruang untuk manouvre. Anda dapat memvalidasi semua permintaan terhadap WSDL itu. Namun karena WSDL tidak menggambarkan layanan REST dengan benar maka Anda tidak memiliki cara yang disepakati untuk menyetujui antarmuka untuk komunikasi.

Dari perspektif bisnis, hal ini tampaknya membuat komunikasi terbuka untuk interpretasi dan perubahan yang tampaknya seperti ide yang buruk.

Top 'Answer' di utas ini tampaknya mengatakan bahwa SOAP singkatan dari Simple Access-oriented Access Protocol, namun melihat wiki O berarti Object bukan Object-oriented. Mereka adalah hal yang berbeda.

Saya tahu posting ini sudah sangat tua tetapi saya pikir saya harus merespons dengan temuan saya sendiri.

7
Exitos

Ini pertanyaan yang bagus ... Saya tidak ingin menyesatkan Anda, jadi saya terbuka untuk jawaban orang lain sebanyak Anda. Bagi saya, itu benar-benar turun ke biaya overhead dan apa gunanya API. Saya lebih suka mengkonsumsi layanan web saat membuat perangkat lunak klien, namun saya tidak suka bobot SOAP. REST, saya percaya, lebih ringan tetapi saya tidak menikmati bekerja dengan itu dari perspektif klien hampir sebanyak.

Saya ingin tahu apa yang dipikirkan orang lain.

6
cranley

Dengarkan podcast ini untuk mencari tahu. Jika Anda ingin tahu jawabannya tanpa mendengarkan, maka OK, REST-nya. Tapi saya sangat merekomendasikan mendengarkan.

6
Mark Beckwith

Aturan umum saya adalah bahwa jika Anda ingin klien web browser untuk langsung terhubung ke layanan maka Anda mungkin harus menggunakan REST. Jika Anda ingin meneruskan data terstruktur antara layanan back-end kemudian gunakan SOAP.

SABUN bisa sangat menyulitkan untuk diatur kadang-kadang dan sering kali terlalu berat untuk klien web dan pertukaran data server sederhana. Sayangnya, sebagian besar contoh pemrograman sederhana yang saya lihat (dan pelajari) agaknya memperkuat persepsi ini.

Yang mengatakan, SOAP benar-benar bersinar ketika Anda mulai menggabungkan beberapa layanan SOAP bersama sebagai bagian dari proses yang lebih besar yang didorong oleh alur kerja data (pikirkan perangkat lunak perusahaan). Ini adalah sesuatu yang banyak contoh pemrograman SOAP gagal untuk disampaikan karena operasi SOAPsederhana _ untuk melakukan sesuatu, seperti mengambil harga saham, umumnya terlalu rumit untuk apa yang dilakukan oleh sendiri kecuali jika disajikan dalam konteks penyediaan API yang dapat dibaca mesin yang merinci fungsi spesifik dengan format data yang ditetapkan untuk input dan output yang, pada gilirannya, dituliskan oleh proses yang lebih besar.

Ini menyedihkan, dengan cara, karena benar-benar memberikan SOAP reputasi buruk karena sulit untuk menunjukkan keuntungan dari SOAP tanpa menyajikannya dalam konteks penuh tentang bagaimana produk akhir digunakan.

6
Rick Sarvas

Dalam arti dengan "PHP-universe" PHP dukungan untuk setiap tingkat lanjut SOAP sangat menyebalkan. Anda akan berakhir menggunakan sesuatu seperti http://wso2.com/products/web-services-framework/php/ segera setelah Anda melewati kebutuhan dasar, bahkan untuk mengaktifkan WS-Security atau WS- RM tidak ada dukungan bawaan.

Pembuatan amplop SOAP saya merasa sangat berantakan di PHP, cara itu menciptakan ruang nama, xsd: nil, xsd: anytype dan layanan sabun gaya lama yang menggunakan SOAP Encoding (Tuhan tahu bagaimana perbedaannya) dengan di SOAP pesan.

Hindari semua kekacauan ini dengan tetap berpegang pada REST, REST bukan hal yang besar yang telah kita gunakan sejak awal WWW. Kami baru menyadari ketika ini http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm makalah yang keluar menunjukkan bahwa kami dapat menggunakan kemampuan HTTP untuk mengimplementasikan Layanan RESTFul. HTTP secara inheren REST, itu tidak berarti hanya menggunakan HTTP membuat layanan Anda RESTFul.

SOAP mengabaikan kemampuan inti HTTP dan menganggap HTTP hanya sebagai protokol transport, maka itu adalah protokol transport yang independen secara teori (dalam praktiknya bukankah Anda pernah mendengar SOAP Action header? Jika tidak google sekarang !).

Dengan peningkatan adaptasi JSON dan HTML5 dengan pematangan javascript REST dengan JSON telah menjadi cara paling umum untuk berurusan dengan layanan. Skema JSON juga telah didefinisikan dapat digunakan untuk solusi tingkat perusahaan (masih dalam tahap awal) bersama dengan WADL jika diperlukan.

Dukungan PHP untuk REST dan JSON jelas lebih baik daripada dukungan inbuilt SOAP yang ada.

Menambahkan beberapa kata BUZZ di sini SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

ngomong-ngomong, aku sangat mencintai SOAP terutama untuk spesifikasi WS-Security, ini adalah salah satu spek yang bagus dan jika seseorang yang berpikir dalam adaptasi Enterprise JSON pasti perlu datang dengan sesuatu yang mirip dengan JSON, seperti enkripsi level lapangan dll. .

4
shivaspk

SOAP mewujudkan pendekatan berorientasi layanan ke layanan Web - yang mana metode (atau kata kerja) adalah cara utama Anda berinteraksi dengan layanan. REST mengambil pendekatan berorientasi sumber daya di mana objek (atau kata benda) mengambil bagian tengah.

4

Satu titik cepat - protokol transmisi dan orkestrasi;

Saya menggunakan SOAP lebih dari TCP untuk alasan kecepatan, keandalan, dan keamanan, termasuk mesin yang dirancang untuk layanan mesin (ESB) dan layanan eksternal. Ubah definisi layanan, orkestrasi memunculkan kesalahan dari perubahan WSDL dan segera jelas dan dapat dibangun kembali/digunakan.

Tidak yakin Anda dapat melakukan hal yang sama dengan REST - Saya menunggu koreksi atau kursus! Dengan REST, ubah definisi layanan - tidak ada yang tahu tentang hal itu sampai mengembalikan 400 (atau apa pun).

3
BlueChippy

Jika Anda mencari interoperabilitas antara berbagai sistem dan bahasa, saya pasti akan mencari REST. Saya punya banyak masalah saat mencoba mendapatkan SOAP bekerja antara .NET dan Java, misalnya.

2
neu242

saya membuat tolok ukur untuk menemukan mana di antara mereka yang lebih cepat! saya melihat hasil ini:

untuk 1000 permintaan:

  • REST memakan waktu 3 detik
  • SABUN butuh 7 detik

untuk 10.000 permintaan:

  • REST mengambil 33 detik
  • SABUN membutuhkan waktu 69 detik

untuk 1.000.000 permintaan:

  • REST mengambil 62 detik
  • SABUN membutuhkan 114 detik
2
Sonador

Sebuah pertanyaan lama tapi masih relevan hari ini .... karena banyak pengembang di ruang perusahaan masih menggunakannya.

Pekerjaan saya melibatkan merancang dan mengembangkan solusi IoT (Internet of Things). Yang termasuk pengembangan kode untuk perangkat tertanam kecil yang berkomunikasi dengan Cloud.

Jelas REST sekarang diterima secara luas dan bermanfaat, dan cukup banyak standar defacto untuk web, bahkan Microsoft memiliki REST dukungan yang disertakan di seluruh Azure. Jika saya perlu mengandalkan SOAP Saya tidak bisa melakukan apa yang perlu saya lakukan, karena terlalu besar, tebal dan menjengkelkan untuk perangkat tertanam kecil.

REST sederhana dan bersih dan kecil. Menjadikannya ideal untuk perangkat tertanam kecil. Saya selalu berteriak ketika saya bekerja dengan pengembang web yang mengirimi saya WSDL. Karena saya harus memulai kampanye pendidikan tentang mengapa ini tidak akan berhasil dan mengapa mereka harus belajar REST.

0
Remixed123

1. Dari pengalaman saya. Saya akan mengatakan REST memberi Anda opsi untuk mengakses URL yang sudah dibuat. misalnya-> pencarian kata di google. URL itu dapat digunakan sebagai layanan web untuk REST. Di SOAP, Anda dapat membuat layanan web Anda sendiri dan mengaksesnya melalui klien SOAP.

  1. REST mendukung teks, JSON, format XML. Karenanya lebih fleksibel untuk berkomunikasi antara dua aplikasi. Sementara SOAP hanya mendukung format XML untuk komunikasi pesan.
0
Shalini Baranwal