Adakah yang bisa menjelaskan apa itu REST dan apa itu SOAP dalam bahasa Inggris? Dan bagaimana Layanan Web bekerja?
Adakah yang bisa menjelaskan apa itu REST dan apa itu SOAP dalam bahasa Inggris? Dan bagaimana Layanan Web bekerja?
Jawaban:
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):
Transfer status representatif (REST):
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
REST
dan SOAP
yang bisa dibilang tidak saling eksklusif. Arsitektur yang tenang mungkin menggunakan HTTP
atau SOAP
atau beberapa protokol komunikasi lainnya. REST
dioptimalkan untuk web dan karenanya HTTP
merupakan pilihan yang sempurna. HTTP
juga satu - satunya protokol yang dibahas dalam makalah Roy Fielding.
Meskipun REST dan SOAP jelas sangat berbeda, pertanyaannya tidak menjelaskan fakta bahwa REST
dan HTTP
sering digunakan bersama-sama. Hal ini terutama disebabkan oleh kesederhanaan HTTP dan pemetaannya yang sangat alami untuk prinsip RESTful.
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.
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.
Jadi - menurut pendapat saya - layanan web SOAP yang paling umum menggunakan gaya pengikatan RPC dan gaya pengkodean literal dan memiliki properti berikut:
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.
Antarmuka yang seragam
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.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 accept
header yang kami kirim dengan permintaan. Misalnya kita dapat mengirim gambar Ny. Smith (mungkin bukan telanjang) jika image/jpeg
diminta.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:
Terkadang sulit untuk memilih ...
Jadi layanan web REST sangat berbeda dari layanan web SOAP (dengan gaya pengikatan RPC dan gaya pengkodean literal)
dan seterusnya...
Layanan web SOAP RPC tidak memenuhi semua kendala REST:
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.
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.
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.