Adakah yang bisa menjelaskan apa itu REST dan apa itu SOAP dalam bahasa Inggris? Dan bagaimana Layanan Web bekerja?

Penjelasan sederhana tentang SOAP dan REST

SOAP - "Protokol Akses Objek Sederhana"

SOAP adalah metode mentransfer pesan, atau sejumlah kecil informasi, melalui Internet. Pesan SOAP diformat dalam XML dan biasanya dikirim menggunakan HTTP (protokol transfer hiperteks).

Istirahat - Representasi status transfer

Istirahat adalah cara sederhana untuk mengirim dan menerima data antara klien dan server dan tidak memiliki standar yang sangat jelas. Anda dapat mengirim dan menerima data sebagai JSON, XML atau bahkan teks biasa. Ini berbobot ringan dibandingkan dengan SABUN.

Kedua metode ini digunakan oleh banyak pemain besar. Ini masalah preferensi. Preferensi saya REST karena lebih mudah digunakan dan dimengerti.

Simple Access Access Protocol (SOAP):

• SOAP membangun protokol XML di atas HTTP atau terkadang TCP / IP.
• SOAP menjelaskan fungsi, dan tipe 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 disandikan terlebih dahulu ke dalam format seperti base64 yang disandikan.
• Memiliki beberapa protokol dan teknologi yang berkaitan dengannya: WSDL, XSDs, SOAP, WS-Addressing

Transfer status representatif (REST):

• REST tidak perlu lebih dari HTTP tetapi sebagian besar poin saya di bawah ini akan memiliki bias HTTP.
• REST sangat ringan, katanya tunggu dulu, kita tidak perlu semua kerumitan yang dibuat SOAP ini.
• Biasanya menggunakan metode HTTP normal alih-alih format XML besar yang menjelaskan semuanya. Misalnya untuk mendapatkan sumber daya yang Anda gunakan HTTP GET, untuk menempatkan sumber daya di server yang Anda gunakan HTTP PUT. Untuk menghapus sumber daya di server Anda menggunakan HTTP DELETE.
• REST sangat sederhana karena menggunakan metode HTTP GET, POST, dan PUT untuk memperbarui sumber daya di server.
• REST biasanya paling baik digunakan dengan Resource Oriented Architecture (ROA). Dalam mode berpikir ini semua adalah sumber daya, dan Anda akan beroperasi pada sumber daya ini.
• Selama bahasa pemrograman Anda memiliki pustaka HTTP, dan sebagian besar melakukannya, Anda dapat mengonsumsi protokol REST HTTP dengan sangat mudah.
• Data biner atau sumber daya biner dapat dengan mudah dikirimkan atas permintaan mereka.

Ada perdebatan tanpa akhir tentang REST vs SOAP di google .

Favorit saya adalah yang ini . Pembaruan 27 Nov 2013: Situs Paul Prescod tampaknya telah offline dan artikel ini tidak lagi tersedia, salinannya dapat ditemukan di Wayback Machine atau sebagai PDF di CiteSeerX .

BERISTIRAHAT

Saya mengerti ide utama REST sangat sederhana. Kami telah menggunakan browser web selama bertahun-tahun dan kami telah melihat betapa mudah, fleksibel, berkinerja, dll situs web. Situs HTML menggunakan hyperlink dan formulir sebagai sarana utama interaksi pengguna. Tujuan utama mereka adalah untuk memungkinkan kami, klien, untuk mengetahui hanya tautan-tautan yang dapat kami gunakan dalam kondisi saat ini . Dan REST hanya mengatakan 'mengapa tidak menggunakan prinsip yang sama untuk menggerakkan komputer daripada klien manusia melalui aplikasi kita?' Kombinasikan ini dengan kekuatan infrastruktur WWW dan Anda akan mendapatkan alat pembunuh untuk membangun aplikasi terdistribusi hebat.

Penjelasan lain yang mungkin adalah untuk orang yang berpikir secara matematis. Setiap aplikasi pada dasarnya adalah mesin negara dengan tindakan logika bisnis menjadi transisi negara. Gagasan REST adalah untuk memetakan setiap transisi ke beberapa permintaan ke sumber daya dan menyediakan klien dengan tautan yang mewakili transisi yang tersedia di negara saat ini. Dengan demikian ia memodelkan mesin negara melalui representasi dan tautan. Inilah sebabnya mengapa disebut Transfer Negara Representasi.

Cukup mengejutkan bahwa semua jawaban tampaknya berfokus pada format pesan, atau pada penggunaan kata kerja HTTP. Bahkan, format pesan tidak masalah sama sekali, REST dapat menggunakan salah satu asalkan pengembang layanan mendokumentasikannya. Kata kerja HTTP hanya menjadikan layanan sebagai layanan CRUD, tetapi belum TETAP. Apa yang benar-benar mengubah layanan menjadi layanan REST adalah hyperlink (alias kontrol hypermedia) yang tertanam ke dalam respons server bersama dengan data, dan jumlahnya harus cukup bagi setiap klien untuk memilih tindakan berikutnya dari tautan tersebut.

Sayangnya, agak sulit untuk menemukan informasi yang benar tentang REST di Web, kecuali untuk tesis Roy Fielding . (Dialah yang berasal REST). Saya akan merekomendasikan buku 'REST in Practice' karena buku ini memberikan tutorial langkah demi langkah yang komprehensif tentang cara berevolusi dari SOAP ke REST.

SABUN MANDI

Ini adalah salah satu kemungkinan bentuk gaya arsitektur RPC (panggilan prosedur jarak jauh). Intinya, itu hanya teknologi yang memungkinkan klien memanggil metode server melalui batas layanan (jaringan, proses, dll) seolah-olah mereka memanggil metode lokal. Tentu saja, sebenarnya berbeda dari memanggil metode lokal dalam kecepatan, keandalan dan sebagainya, tetapi idenya sesederhana itu.

Dibandingkan

Detail seperti protokol transport, format pesan, xsd, wsdl, dll. Tidak masalah ketika membandingkan segala bentuk RPC dengan REST. Perbedaan utama adalah bahwa layanan RPC menciptakan kembali sepeda dengan merancang protokol aplikasi sendiri di RPC API dengan semantik yang hanya diketahui olehnya. Oleh karena itu, semua klien harus memahami protokol ini sebelum menggunakan layanan, dan tidak ada infrastruktur generik seperti cache dapat dibangun karena semantik eksklusif dari semua permintaan. Lebih jauh, RPC API tidak menyarankan tindakan apa yang diizinkan dalam kondisi saat ini, ini harus berasal dari dokumentasi tambahan. REST di sisi lain menyiratkan menggunakan antarmuka yang seragam untuk memungkinkan berbagai klien memiliki pemahaman tentang semantik API, dan kontrol hypermedia (tautan) untuk menyoroti opsi yang tersedia di setiap negara. Jadi,

Di satu sisi, SOAP (seperti RPC lainnya) adalah upaya untuk menerobos batas layanan yang memperlakukan media penghubung sebagai kotak hitam yang hanya mampu mengirim pesan. REST adalah keputusan untuk mengakui bahwa Web adalah sistem informasi terdistribusi yang besar, untuk menerima dunia apa adanya dan belajar untuk menguasainya alih-alih berjuang melawannya.

SOAP tampaknya bagus untuk API jaringan internal, ketika Anda mengontrol server dan klien, dan sementara interaksinya tidak terlalu rumit. Lebih alami bagi pengembang untuk menggunakannya. Namun, untuk API publik yang digunakan oleh banyak pihak independen, rumit dan besar, REST harus lebih baik. Tetapi perbandingan terakhir ini sangat kabur.

Memperbarui

Pengalaman saya secara tak terduga menunjukkan pengembangan REST lebih sulit daripada SOAP. Setidaknya untuk .NET. Meskipun ada kerangka kerja yang bagus seperti ASP.NET Web API, tidak ada tooling yang secara otomatis akan menghasilkan proxy sisi klien. Tidak seperti 'Tambahkan Referensi Layanan Web' atau 'Tambahkan Referensi Layanan WCF'. Kita harus menulis semua serialisasi dan kode permintaan layanan dengan tangan. Dan kawan, itu banyak kode boilerplate. Saya pikir pengembangan REST membutuhkan sesuatu yang mirip dengan WSDL dan implementasi tooling untuk setiap platform pengembangan. Bahkan, tampaknya ada landasan yang bagus: WADL atau WSDL 2.0 , tetapi tidak satu pun dari standar tersebut yang tampaknya didukung dengan baik.

Pembaruan (Jan 2016)

Ternyata sekarang ada berbagai alat untuk definisi REST API. Preferensi pribadi saya saat ini adalah RAML .

Bagaimana Layanan Web bekerja

Nah, ini pertanyaan yang terlalu luas, karena itu tergantung pada arsitektur dan teknologi yang digunakan dalam layanan web tertentu. Tetapi secara umum, layanan web hanyalah beberapa aplikasi di Web yang dapat menerima permintaan dari klien dan mengembalikan respons. Ini terpapar ke Web, jadi ini adalah layanan web , dan biasanya tersedia 24/7, itu sebabnya layanan . Tentu saja, ini memecahkan beberapa masalah (jika tidak, mengapa seseorang akan menggunakan layanan web) untuk kliennya.

Ini adalah penjelasan paling sederhana yang pernah Anda temukan.

Artikel ini mengambil narasi suami-istri, di mana suami menjelaskan kepada istrinya tentang REST, dalam istilah awam murni. Harus baca!

bagaimana-aku-jelaskan-istirahat-untuk-istriku (tautan asli)
how-i-menjelaskan-rest-to-my-wife (2013-07-19 tautan kerja)

SOAP - Protokol Akses Objek Sederhana adalah protokol !

REST - Transfer Negara Representatif adalah gaya arsitektur !

SOAP adalah protokol XML yang digunakan untuk mentransfer pesan, biasanya melalui HTTP

RESTdan SOAPyang bisa dibilang tidak saling eksklusif. Arsitektur yang tenang mungkin menggunakan HTTPatau SOAPatau beberapa protokol komunikasi lainnya. RESTdioptimalkan untuk web dan karenanya HTTPmerupakan pilihan yang sempurna. HTTPjuga satu - satunya protokol yang dibahas dalam makalah Roy Fielding.

Meskipun REST dan SOAP jelas sangat berbeda, pertanyaannya tidak menjelaskan fakta bahwa RESTdan HTTPsering digunakan bersama-sama. Hal ini terutama disebabkan oleh kesederhanaan HTTP dan pemetaannya yang sangat alami untuk prinsip RESTful.

Prinsip REST Fundamental

Komunikasi Client-Server

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

Tanpa kewarganegaraan

Setiap setiap permintaan klien ke server mensyaratkan bahwa negaranya sepenuhnya diwakili. Server harus dapat sepenuhnya memahami permintaan klien tanpa menggunakan konteks server atau status sesi server apa pun. Oleh karena itu, semua status harus disimpan pada klien. Kami akan membahas perwakilan tanpa negara secara lebih rinci nanti.

Cacheable

Batasan cache dapat digunakan, sehingga memungkinkan data respons ditandai sebagai dapat disimpan atau tidak. Setiap data yang ditandai sebagai dapat disimpan kembali dapat digunakan kembali sebagai respons terhadap permintaan berikutnya yang sama.

Antarmuka Seragam

Semua komponen harus berinteraksi melalui antarmuka seragam tunggal. Karena semua interaksi komponen terjadi melalui antarmuka ini, interaksi dengan berbagai layanan sangat sederhana. Antarmukanya sama! Ini juga berarti bahwa perubahan implementasi dapat dilakukan secara terpisah. Perubahan seperti itu, tidak akan mempengaruhi interaksi komponen mendasar karena antarmuka yang 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, sisi baiknya, REST dioptimalkan untuk web, karenanya popularitas REST yang luar biasa atas HTTP!

Konsep di atas menggambarkan karakteristik REST dan membedakan arsitektur REST dari arsitektur lain seperti layanan web. Penting untuk dicatat bahwa layanan REST adalah layanan web, tetapi layanan web belum tentu merupakan layanan REST.

Lihat posting blog ini di Prinsip - prinsip Desain REST untuk detail lebih lanjut tentang REST dan butir-butir di atas.

Saya suka jawaban Brian R. Bondy. Saya hanya ingin menambahkan bahwa Wikipedia memberikan deskripsi yang jelas tentang REST . Artikel itu membedakannya dari SOAP.

REST adalah pertukaran informasi negara, dilakukan sesederhana mungkin.

SOAP adalah protokol pesan yang menggunakan XML.

Salah satu alasan utama bahwa banyak orang telah pindah dari SOAP ke REST adalah bahwa standar WS- * (disebut WS splat) yang terkait dengan layanan web berbasis SOAP sangat rumit. Lihat wikipedia untuk daftar spesifikasinya. Masing-masing spesifikasi ini sangat rumit.

EDIT: karena alasan tertentu tautan tidak ditampilkan dengan benar. REST = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS- *

Baik layanan web SOAP dan layanan web REST dapat menggunakan protokol HTTP dan protokol lain juga (hanya untuk menyebutkan SOAP dapat menjadi protokol yang mendasari REST). Saya hanya akan berbicara tentang protokol HTTP terkait SOAP dan REST, karena ini adalah penggunaan yang paling sering.

SABUN MANDI

SOAP (protokol akses objek "sederhana") adalah protokol (dan standar W3C ). Ini mendefinisikan cara membuat, mengirim dan memproses pesan SOAP.

• Pesan SOAP adalah dokumen XML dengan struktur tertentu: pesan tersebut berisi amplop yang berisi header dan bagian tubuh. Badan berisi data aktual - yang ingin kami kirim - dalam format XML. Ada dua gaya pengkodean , tetapi kami biasanya memilih literal , yang berarti bahwa aplikasi kami atau driver SOAP-nya melakukan serialisasi XML dan unserialisasi data.

• Pesan SOAP berjalan sebagai pesan HTTP dengan subtipe SOAP + XML MIME. Pesan HTTP ini dapat terdiri dari beberapa bagian, sehingga secara opsional kita dapat melampirkan file ke pesan SOAP.

• Jelas kami menggunakan arsitektur client-server, sehingga klien SOAP mengirim permintaan ke server web SOAP dan layanan mengirimkan tanggapan kepada klien. Sebagian besar layanan web menggunakan file WSDL untuk menggambarkan layanan. File WSDL berisi Skema XML (XSD selanjutnya) dari data yang ingin kami kirim dan pengikatan WSDL yang mendefinisikan bagaimana layanan web terikat dengan protokol HTTP. Ada dua gaya yang mengikat: RPC dan dokumen. Dengan gaya RPC mengikat tubuh SOAP berisi representasi dari panggilan operasi dengan parameter (permintaan HTTP) atau nilai kembali (respon HTTP). Parameter dan nilai kembali divalidasi terhadap XSD. Dengan gaya dokumen yang mengikat tubuh SOAP berisi dokumen XML yang divalidasi terhadap XSD. Saya pikir gaya mengikat dokumen lebih cocok untuk sistem berbasis acara, tapi saya tidak pernah menggunakan gaya mengikat itu. Gaya mengikat RPC lebih lazim, sehingga kebanyakan orang menggunakan SOAP untuk keperluan XML / RPC oleh aplikasi terdistribusi. Layanan web biasanya menemukan satu sama lain dengan menanyakan server UDDI . Server UDDI adalah pendaftar yang menyimpan lokasi layanan web.

RAP SABUN

Jadi - menurut pendapat saya - layanan web SOAP yang paling umum menggunakan gaya pengikatan RPC dan gaya pengkodean literal dan memiliki properti berikut:

• Ini memetakan URL ke operasi.
• Ini mengirim pesan dengan subtipe SOAP + XML MIME.
• Itu dapat memiliki toko sesi sisi server, tidak ada kendala tentang itu.
• Driver klien SOAP menggunakan file WSDL dari layanan untuk mengubah operasi RPC menjadi metode. Aplikasi sisi klien berkomunikasi dengan layanan web SOAP dengan memanggil metode ini. Jadi sebagian besar klien SOAP dipecah oleh perubahan antarmuka (menghasilkan nama metode dan / atau perubahan parameter).
• Dimungkinkan untuk menulis klien SOAP yang tidak akan rusak oleh perubahan antarmuka menggunakan RDF dan menemukan operasi dengan semantik, tetapi layanan web semantik sangat jarang dan mereka tidak selalu memiliki klien yang tidak melanggar (saya kira).

BERISTIRAHAT

REST (transfer negara representasional) adalah gaya arsitektur yang dijelaskan dalam disertasi Roy Fielding. Itu tidak peduli tentang protokol seperti SOAP. Itu dimulai dengan gaya arsitektur nol yang tidak memiliki kendala dan mendefinisikan kendala arsitektur REST satu per satu. Orang menggunakan istilah RESTful untuk layanan web yang memenuhi semua kendala REST, tetapi menurut Roy Fielding, tidak ada yang namanya level REST . Ketika layanan web tidak bertemu dengan setiap kendala REST, maka itu bukan layanan web REST.

Kendala REST

• Klien - arsitektur server - Saya pikir bagian ini akrab bagi semua orang. Klien REST berkomunikasi dengan layanan web REST, layanan web mempertahankan data umum - status sumber daya setelahnya - dan menyajikannya kepada klien.
• Stateless - Bagian "transfer negara" dari singkatan: REST. Klien mempertahankan status klien (sesi / status aplikasi), sehingga layanan tidak boleh memiliki penyimpanan sesi. Klien mentransfer bagian yang relevan dari negara klien dengan setiap permintaan ke layanan yang merespons dengan bagian yang relevan dari negara sumber daya (dikelola oleh mereka). Jadi permintaan tidak memiliki konteks, mereka selalu berisi informasi yang diperlukan untuk memprosesnya. Misalnya dengan HTTP dasar, nama pengguna dan kata sandi disimpan oleh klien, dan mengirimkannya dengan setiap permintaan, sehingga otentikasi terjadi oleh setiap permintaan. Ini sangat berbeda dari aplikasi web biasa di mana otentikasi hanya terjadi dengan masuk. Kita dapat menggunakan mekanisme penyimpanan data sisi klien seperti di-memori (javascript), cookie, penyimpanan lokal, dan sebagainya ... untuk bertahan beberapa bagian dari keadaan klien jika kita mau Alasan kendala kewarganegaraan, bahwa server berskala baik - bahkan oleh beban yang sangat tinggi (jutaan pengguna) - ketika tidak harus mempertahankan sesi setiap klien.
• Cache - Respons harus berisi informasi tentang hal itu dapat di-cache oleh klien atau tidak. Ini meningkatkan skalabilitas lebih lanjut.

• Antarmuka yang seragam

  • Identifikasi sumber daya - Sumber daya REST sama dengan sumber daya RDF . Menurut Fielding jika Anda dapat memberi nama sesuatu, maka itu dapat menjadi sumber daya, misalnya: "cuaca lokal saat ini" dapat menjadi sumber daya, atau "ponsel Anda" dapat menjadi sumber daya, atau "dokumen web tertentu" dapat menjadi sumber daya. Untuk mengidentifikasi sumber daya, Anda dapat menggunakan pengidentifikasi sumber daya: URL dan URN (misalnya nomor ISBN berdasarkan buku ). Pengidentifikasi tunggal harus hanya dimiliki oleh sumber daya tertentu, tetapi sumber daya tunggal dapat memiliki banyak pengidentifikasi, yang sering kita eksploitasi misalnya dengan pagination dengan URL seperti https://example.com/api/v1/users?offset=50&count=25. URL punya beberapa spesifikasi, misalnya URL dengan jalur yang sama tetapi kueri yang berbeda tidak identik, atau bagian jalur harus berisi data hierarkis dari URL dan bagian permintaan harus berisi data non-hierarkis. Ini adalah dasar-dasar cara membuat URL oleh REST. Btw. struktur URL hanya penting bagi pengembang layanan, klien REST nyata tidak memedulikannya. Pertanyaan lain yang sering diajukan adalah versi API, yang merupakan pertanyaan yang mudah, karena menurut Fielding, satu-satunya yang konstan oleh sumber daya adalah semantik. Jika semantiknya berubah, maka Anda dapat menambahkan nomor versi baru. Anda dapat menggunakan versi 3 angka klasik dan hanya menambahkan nomor utama ke URL (https://example.com/api/v1/). Jadi dengan perubahan yang kompatibel ke belakang tidak terjadi apa-apa, dengan perubahan yang tidak kompatibel ke belakang, Anda akan memiliki semantik yang tidak kompatibel dengan akar API baru https://example.com/api/v2/. Jadi klien lama tidak akan putus, karena mereka dapat menggunakan https://example.com/api/v1/dengan semantik lama.
  • Manipulasi sumber daya melalui representasi - Anda dapat memanipulasi data yang terkait dengan sumber daya (keadaan sumber daya) dengan mengirimkan representasi sumber daya yang dimaksudkan - bersama dengan metode HTTP dan pengidentifikasi sumber daya - ke layanan REST. Misalnya, jika Anda ingin mengganti nama pengguna setelah menikah, Anda dapat mengirim PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}permintaan yang {name: "Mrs Smith"}merupakan representasi JSON dari status sumber daya yang dimaksud, dengan kata lain: nama baru. Ini terjadi vica-sebaliknya, layanan mengirimkan representasi sumber daya ke klien untuk mengubah status mereka. Sebagai contoh jika kita ingin membaca nama baru, kita dapat mengirim GET https://example.com/api/v1/users/1?fields="name"permintaan pengambilan, yang menghasilkan a200 ok, {name: "Mrs Smith"}tanggapan. Jadi kita dapat menggunakan representasi ini untuk mengubah keadaan klien, misalnya kita dapat menampilkan "Selamat datang di halaman kami, Nyonya Smith!" pesan. Sumber daya dapat memiliki banyak representasi tergantung pada pengidentifikasi sumber daya (URL) atau acceptheader yang kami kirim dengan permintaan. Misalnya kita dapat mengirim gambar Ny. Smith (mungkin bukan telanjang) jika image/jpegdiminta.
  • Pesan deskriptif sendiri - Pesan harus berisi informasi tentang cara memprosesnya. Misalnya metode URI dan HTTP, header tipe konten, header cache, RDF yang menjelaskan arti data, dll ... Penting untuk menggunakan metode standar. Penting untuk mengetahui spesifikasi metode HTTP. Misalnya GET berarti mengambil informasi yang diidentifikasi oleh URL permintaan, DELETE berarti meminta server untuk menghapus sumber daya yang diidentifikasi oleh URL yang diberikan, dan seterusnya ... Kode status HTTP memiliki spesifikasi juga, misalnya 200 berarti sukses, 201 berarti sumber daya baru telah dibuat, 404 berarti bahwa sumber daya yang diminta tidak ditemukan di server, dll ... Menggunakan standar yang ada adalah bagian penting dari REST.

  • Hypermedia sebagai mesin status aplikasi (HATEOAS selanjutnya) - Hypermedia adalah jenis media yang dapat berisi hyperlink. Melalui web kami mengikuti tautan - dijelaskan oleh format hypermedia (biasanya HTML) - untuk mencapai tujuan, alih-alih mengetik URL ke bilah alamat. REST mengikuti konsep yang sama, representasi yang dikirim oleh layanan dapat berisi hyperlink. Kami menggunakan hyperlink ini untuk mengirim permintaan ke layanan. Dengan respons kita mendapatkan data (dan mungkin lebih banyak tautan) yang dapat kita gunakan untuk membangun status klien baru, dan seterusnya ... Jadi itu sebabnya hypermedia adalah mesin status aplikasi (status klien). Anda mungkin bertanya-tanya bagaimana klien mengenali dan mengikuti hyperlink? Oleh manusia itu cukup sederhana, kita membaca judul tautan, mungkin mengisi kolom input, dan setelah itu hanya satu klik.JSON-LD dengan Hydra ) atau dengan solusi spesifik hypermedia (misalnya hubungan tautan IANA dan tipe MIME khusus vendor oleh HAL + JSON ). Ada banyak format hypermedia XML dan JSON yang dapat dibaca mesin , hanya daftar pendek dari mereka:

    • XHTML
    • ATOM + XML
    • RDF + XML
    • HAL + XML
    • HAL + JSON
    • JSON-LD
    • RDF + JSON
    • Sirene
    • Koleksi + JSON

    Terkadang sulit untuk memilih ...

• Sistem berlapis - Kami dapat menggunakan beberapa lapisan antara klien dan layanan. Tak satu pun dari mereka harus tahu tentang semua lapisan tambahan ini, hanya lapisan tepat di sebelahnya. Lapisan-lapisan ini dapat meningkatkan skalabilitas dengan menerapkan cache dan load balancing atau mereka dapat menegakkan kebijakan keamanan.
• Kode atas permintaan - Kami dapat mengirim kembali kode yang memperluas fungsionalitas klien, misalnya kode javascript ke browser. Ini adalah satu-satunya kendala opsional REST.

Layanan web REST - Perbedaan layanan web SOAP RPC

Jadi layanan web REST sangat berbeda dari layanan web SOAP (dengan gaya pengikatan RPC dan gaya pengkodean literal)

• Ini mendefinisikan antarmuka yang seragam (bagian dari protokol).
• Ini memetakan URL ke sumber daya (dan bukan operasi).
• Ia mengirim pesan dengan tipe MIME apa saja (bukan hanya SOAP + XML).
• Ini memiliki komunikasi stateless, dan sehingga tidak dapat memiliki penyimpanan sesi sisi server. (SABUN tidak memiliki kendala tentang ini)
• Ini melayani hypermedia dan klien menggunakan tautan yang terkandung oleh hypermedia untuk meminta layanan. (SOAP RPC menggunakan binding operasi yang dijelaskan dalam file WSDL)
• Itu tidak rusak oleh perubahan URL hanya oleh perubahan semantik. (SOAP RPC klien tanpa menggunakan semantik RDF dipecah oleh perubahan file WSDL.)
• Ini skala lebih baik daripada layanan web SOAP karena perilaku stateless.

dan seterusnya...

Layanan web SOAP RPC tidak memenuhi semua kendala REST:

• arsitektur client-server - selalu
• stateless - mungkin
• cache - mungkin
• antarmuka seragam - tidak pernah
• sistem berlapis - tidak pernah
• kode sesuai permintaan (opsional) - mungkin

Baiklah saya akan mulai dengan pertanyaan kedua: Apa itu Layanan Web? , untuk alasan yang jelas.

WebServices pada dasarnya adalah potongan-potongan logika (yang secara samar-samar Anda sebut sebagai metode) yang mengekspos fungsionalitas atau data tertentu. Implementasi klien (berbicara secara teknis, mengkonsumsi adalah kata) hanya perlu tahu apa parameter yang akan diterima oleh metode dan jenis data yang akan dikembalikan (jika memang demikian).

Tautan berikut mengatakan semuanya tentang REST & SOAP dengan cara yang sangat jelas.

SISA vs SABUN

Jika Anda juga ingin tahu kapan harus memilih apa (REST atau SOAP), semakin banyak alasan untuk melewatinya!

SOAP dan REST keduanya merujuk pada cara-cara sistem yang berbeda untuk berbicara satu sama lain.

REST melakukan ini menggunakan teknik yang menyerupai komunikasi yang dimiliki browser Anda dengan server web: menggunakan GET untuk meminta halaman web, POSTing dalam bidang formulir, dll.

SOAP menyediakan sesuatu yang serupa tetapi melakukan segalanya melalui mengirimkan blok XML bolak-balik. Komponen kunci lain dari SOAP adalah WSDL yang merupakan dokumen XML yang menjelaskan fungsi dan elemen data apa yang didukung. WSDL dapat digunakan untuk "menemukan" fungsi apa yang didukung secara terprogram serta untuk menghasilkan potongan kode pemrograman.

Saya pikir ini semudah yang saya bisa jelaskan. Tolong, siapa pun boleh memperbaiki saya atau menambahkan ini.

SOAP adalah format pesan yang digunakan oleh sistem terputus (seperti di internet) untuk bertukar informasi / data. Itu dengan pesan XML bolak-balik.

Layanan web mengirim atau menerima pesan SOAP. Mereka bekerja secara berbeda tergantung pada bahasa apa mereka ditulis.

Masalah dengan SOAP adalah bahwa itu bertentangan dengan cita-cita di balik tumpukan HTTP. Setiap middleware harus dapat bekerja dengan permintaan HTTP tanpa memahami konten permintaan atau respons, tetapi misalnya server cache HTTP biasa tidak akan bekerja dengan permintaan SOAP tanpa hanya mengetahui bagian mana dari konten SOAP yang penting untuk di-cache. SOAP hanya menggunakan HTTP sebagai pembungkus untuk protokol komunikasinya sendiri, seperti proxy.

REST adalah gaya arsitektur untuk merancang aplikasi jaringan. Idenya adalah bahwa, daripada menggunakan mekanisme yang kompleks seperti CORBA, RPC atau SOAP untuk menghubungkan antar mesin, HTTP sederhana digunakan untuk melakukan panggilan antar mesin.

SOAP - "Protokol Akses Objek Sederhana"

SOAP adalah sedikit mentransfer pesan, atau sejumlah kecil informasi melalui Internet. Pesan SOAP diformat dalam XML dan biasanya dikirim mengendalikan HTTP .

REST - "Transfer Negara Representatif"

REST adalah proses yang belum sempurna dari kemungkinan dan menerima informasi antara fan dan server dan tidak memiliki banyak standar yang jelas. Anda dapat mengirim dan menerima informasi sebagai JSON , XML atau bahkan teks biasa. Ini berbobot ringan dibandingkan dengan SABUN .

Layanan Web Berbasis SOAP Singkatnya, model Layanan SOAP memandang dunia sebagai ekosistem rekan sejawat yang tidak dapat saling mengontrol, tetapi harus bekerja sama dengan menghormati kontrak yang diterbitkan. Ini adalah model yang valid dari dunia nyata yang berantakan, dan kontrak berbasis metadata membentuk Antarmuka Layanan SOAP.

kita masih dapat mengaitkan SOAP dengan Panggilan Prosedur Jarak Jauh berbasis XML, tetapi teknologi Layanan Web berbasis SOAP telah muncul menjadi model pesan yang fleksibel dan kuat.

SOAP mengasumsikan semua sistem independen dan tidak ada sistem yang memiliki pengetahuan tentang fungsi internal dan internal lainnya. Sistem yang paling bisa dilakukan adalah mengirim pesan satu sama lain dan berharap mereka akan ditindaklanjuti. Sistem menerbitkan kontrak yang mereka lakukan untuk menghormati, dan sistem lain bergantung pada kontrak ini untuk bertukar pesan dengan mereka.

Kontrak antara sistem secara kolektif disebut metadata, dan terdiri dari deskripsi layanan, pola pertukaran pesan yang didukung dan kebijakan yang mengatur kualitas layanan (layanan mungkin perlu dienkripsi, disampaikan dengan andal, dll.) Deskripsi layanan, pada gilirannya, adalah rincian spesifikasi data (dokumen pesan) yang akan dikirim dan diterima oleh sistem. Dokumen-dokumen tersebut dijelaskan menggunakan bahasa deskripsi XML seperti XML Schema Definition. Selama semua sistem menghormati kontrak yang diterbitkan, mereka dapat saling beroperasi, dan perubahan internal sistem tidak pernah memengaruhi yang lain. Setiap sistem bertanggung jawab untuk menerjemahkan implementasi internalnya sendiri ke dan dari kontraknya

REST - Transfer Negara Representatif. Protokol fisik adalah HTTP. Pada dasarnya, REST adalah semua sumber daya berbeda di web yang dapat diidentifikasi secara unik oleh URL. Semua operasi yang dapat dilakukan pada sumber daya ini dapat dijelaskan dengan seperangkat kata kerja terbatas (kata kerja "CRUD") yang pada gilirannya memetakan ke kata kerja HTTP.

REST jauh lebih sedikit "kelas berat" dari SABUN.

Bekerja dengan layanan web