Mengapa kita membutuhkan Layanan Web RESTful?


123

Saya akan mempelajari layanan web RESTful (lebih baik mengatakan bahwa saya harus melakukan ini karena ini adalah bagian dari program gelar master Ilmu Komputer).

Saya telah membaca beberapa info di Wikipedia dan saya juga membaca artikel tentang REST di Sun Developer Network dan saya melihat bahwa ini bukanlah teknologi yang mudah, ada kerangka kerja khusus untuk membangun aplikasi RESTful, dan ini sering dibandingkan dengan layanan web SOAP dan programmer harus memahami kapan harus menggunakan SOAP dan kapan REST bisa menjadi pendekatan yang bagus.

Saya ingat beberapa tahun yang lalu SOAP sangat populer (fashionable?) Dan item 'SOAP' harus ada di setiap CV yang bagus. Namun dalam praktiknya, ini sangat jarang digunakan dan untuk mencapai tujuan yang sangat sederhana.

Tampak bagi saya bahwa REST adalah 'kata terakhir mode' lainnya (atau saya bisa salah total karena saya belum pernah melihat REST dalam latihan).

Dapatkah Anda memberi saya beberapa contoh apakah REST harus digunakan dan mengapa kita tidak dapat melakukan hal yang sama tanpa REST (atau mengapa kita harus menghabiskan lebih banyak waktu untuk melakukan hal yang sama tanpa REST)?

UPD : Sayangnya saya tidak bisa melihat argumen konkret yang bisa membuat saya terheran-heran di komentar pertama. Buat saya berpikir bahwa REST adalah teknologi yang luar biasa!

Saya ingin melihat jawaban seperti ini:

Saya sedang mengembangkan aplikasi HelloWorld kompleks lainnya dan kami perlu mentransfer banyak / data kecil dan saya mengusulkan solusi REST kepada rekan kerja saya:

- Oh sial! Jonny, kita pasti harus menggunakan REST untuk mengimplementasikan aplikasi ini!
- Ya, Billy, kita bisa menggunakan REST, tapi sebaiknya kita menggunakan SOAP. Percayalah karena saya tahu sesuatu tentang mengembangkan aplikasi HelloWorld.
- Tapi SOAP adalah teknologi kuno dari abad terakhir dan kita bisa menggunakan yang lebih baik.
- Billy, apakah Anda siap menghabiskan 3 hari untuk bereksperimen dengan REST? Kita bisa melakukan ini dengan SOAP dalam 2 jam ..
- Ya, saya yakin kita akan menghabiskan lebih banyak waktu untuk mencapai keamanan / kinerja / / skalabilitas / apapun yang sama dengan SOAP. Saya yakin aplikasi HelloWorld seharusnya dikembangkan hanya dengan REST mulai sekarang.


2
Ini bukan teknologi yang luar biasa - ini adalah teknologi yang berbeda. Jika Anda ingin seseorang meyakinkan Anda bahwa itu luar biasa dan harus digunakan setiap saat, cobalah konsultan.
quillbreaker

Jawaban:


133

SISA harus digunakan jika sangat penting bagi Anda untuk meminimalkan coupling antara klien dan server komponen dalam aplikasi terdistribusi.

Ini mungkin terjadi jika server Anda akan digunakan oleh banyak klien berbeda yang tidak dapat Anda kendalikan. Mungkin juga terjadi jika Anda ingin dapat memperbarui server secara teratur tanpa perlu memperbarui perangkat lunak klien.

Saya dapat meyakinkan Anda bahwa mencapai tingkat rendah kopling adalah tidak mudah dilakukan . Sangat penting untuk mengikuti semua kendala REST agar berhasil. Mempertahankan koneksi murni tanpa kewarganegaraan itu sulit. Memilih jenis media yang tepat dan memasukkan data Anda ke dalam format itu rumit. Membuat jenis media Anda sendiri bisa jadi lebih sulit.

Mengadaptasi perilaku server yang kaya ke dalam antarmuka HTTP yang seragam dapat membingungkan dan terkadang tampak terlalu berlebihan dibandingkan dengan pendekatan RPC yang relatif mudah.

Terlepas dari kesulitannya, keuntungannya adalah Anda memiliki layanan yang harus dapat dipahami dengan mudah oleh pengembang klien karena penggunaan protokol HTTP yang konsisten. Layanan harus mudah ditemukan karena hypermedia dan klien harus sangat tahan terhadap perubahan di server .

Manfaat hypermedia dan penghindaran status sesi membuat penyeimbangan beban menjadi sederhana dan pemartisian layanan dapat dilakukan . Kepatuhan yang ketat terhadap aturan HTTP membuat ketersediaan alat seperti debugger dan proxy caching menjadi hal yang luar biasa.

Memperbarui

Tampak bagi saya bahwa REST adalah 'kata terakhir mode' lainnya (atau saya bisa salah total karena saya belum pernah melihat REST dalam latihan).

Saya pikir REST telah menjadi mode karena orang-orang yang mencoba melakukan proyek tipe SOA telah menemukan bahwa menggunakan tumpukan SOAP mereka tidak menyadari manfaat yang dijanjikan. Orang-orang terus kembali ke web sebagai contoh metodologi integrasi sederhana. Sayangnya, menurut saya orang meremehkan jumlah perencanaan dan pandangan ke depan yang digunakan untuk membuat web dan mereka terlalu menyederhanakan apa yang perlu dilakukan untuk memungkinkan jenis penggunaan kembali yang tidak disengaja yang terjadi di web.

Anda mengatakan bahwa Anda belum pernah melihat REST dalam praktiknya, tetapi itu tidak mungkin benar jika Anda pernah menggunakan browser web. Browser web adalah klien REST.

  • Mengapa Anda tidak perlu melakukan pembaruan browser saat seseorang mengubah beberapa html di situs web?
  • Mengapa saya dapat menambahkan satu set lengkap halaman baru ke situs web dan "klien" masih dapat mengakses halaman baru tersebut tanpa update?
  • Mengapa saya tidak perlu memberikan "bahasa-deskripsi-layanan" ke browser web untuk memberi tahu ketika masuk ke http://example.org/images/cat bahwa jenis yang dikembalikan adalah gambar jpeg dan kapan Anda pergi ke http://example.org/description/cat jenis kembaliannya adalah text / html?
  • Mengapa saya dapat menggunakan browser web untuk mengunjungi situs yang tidak ada saat browser dirilis? Bagaimana klien mengetahui tentang situs ini?

Ini mungkin terdengar seperti pertanyaan yang tidak masuk akal, tetapi jika Anda tahu jawabannya, maka Anda dapat mulai melihat apa itu REST. Lihat StackOverflow untuk manfaat REST lainnya. Saat saya melihat sebuah pertanyaan, saya dapat menandai halaman itu atau mengirim url ke teman dan dia dapat melihat informasi yang sama. Dia tidak perlu menjelajahi situs untuk menemukan pertanyaan itu.

StackOverflow menggunakan berbagai layanan OpenId untuk otentikasi, gravatar.com untuk gambar avatar, google-analytics dan Quantserve untuk informasi analitis. Integrasi multi-perusahaan semacam ini adalah jenis hal yang hanya diimpikan oleh dunia SOAP . Salah satu contoh terbaik adalah fakta bahwa pustaka jQuery yang digunakan untuk menggerakkan UI StackOverflow diambil dari Jaringan Pengiriman Konten Google. Fakta bahwa SO dapat mengarahkan klien (yaitu browser web Anda) untuk mengunduh kode dari situs pihak ketiga untuk meningkatkan kinerja adalah bukti rendahnya hubungan antara klien web dan server.

Ini adalah contoh arsitektur REST yang sedang bekerja.

Sekarang beberapa situs web / aplikasi melanggar aturan REST dan kemudian browser tidak berfungsi seperti yang diharapkan.

  • Masalah tombol kembali yang terkenal disebabkan oleh penggunaan status sesi sisi server.
  • Penyeimbangan beban dapat menjadi masalah ketika Anda memiliki status sesi sisi server.
  • Aplikasi flash sering kali mencegah URL mengidentifikasi representasi secara khusus.
  • Masalah lain yang merusak browser web adalah kesesuaian yang buruk dengan standar jenis media. Kami selalu mendengar tentang bagaimana IE6 perlu dimatikan. Masalahnya adalah standar tidak diikuti dengan benar, atau diabaikan karena alasan apa pun.
  • Penggunaan sesi login adalah sumber dari banyak celah keamanan.

REST ada dimana-mana. Ini adalah bagian dari web yang membuatnya berfungsi dengan baik. Jika Anda ingin membuat aplikasi terdistribusi yang dapat berskala seperti web, tahan terhadap perubahan seperti web dan promosikan penggunaan kembali seperti yang telah dilakukan web, kemudian ikuti aturan yang sama seperti yang mereka lakukan saat membuat browser web.


@ Darrell: bagaimana REST mengurangi kopling melalui SOAP? Atau, bagaimana SOAP meningkatkan kopling melalui REST? Apakah Anda mengacu pada fakta bahwa klien SOAP sebenarnya perlu memahami SOAP, tetapi klien REST hanya perlu memahami jenis media?
John Saunders

4
@ John Umumnya cara SOAP digunakan menyebabkan klien memerlukan pengetahuan "terkompilasi" dari setiap titik akhir sisi server, setiap tipe data parameter, dan setiap tipe kembalian. Tidak ada panduan di dunia SOAP untuk mencoba dan menggunakan tipe standar untuk melewatkan data antara klien dan server. Itu berarti bahwa setiap layanan baru yang digunakan oleh pengembang klien, memiliki kumpulan jenis, titik akhir, dan protokol interaksi yang unik. Itu kopling.
Darrel Miller

@John REST mencoba menstandarkan protokol interaksi ke semantik kata kerja HTTP, format data ke tipe terdaftar IANA dan semua titik akhir harus dapat ditemukan secara dinamis. Itu berarti penggandengan klien / server dilokalkan ke definisi jenis media. Seperti yang dikatakan Rich, "layanan Anda mempersempit ruang lingkup penggandengan hanya pada satu hal - jenis media."
Darrel Miller

@Darrell: itu bukanlah penggabungan dalam pengertian tradisional. Klien dapat dianggap "digabungkan" ke metadata (WSDL), tetapi tidak ke layanan. Pertimbangkan layanan yang mengembalikan "Karyawan": {int id; string firstName, lastName, streetAddress1, streetAddress2, city, state; int zip;}. Anda sepertinya menyarankan agar kami mendaftarkan "Karyawan" dengan IANA, atau kami hanya menganggap "Karyawan" sebagai larik asosiatif dari pasangan nama / nilai.
John Saunders

@ John Biarkan saya mendefinisikan apa yang saya maksud dengan penggandengan dalam istilah WSDL. Bayangkan bisa memiliki kontrak layanan yang Anda dapat menambahkan metode, menghapus metode dan mengganti nama metode tanpa harus mengkompilasi ulang klien. Pertimbangkan juga bahwa klien dapat diarahkan untuk menggunakan metode baru ini tanpa kompilasi ulang. Kontrak pesan ditetapkan oleh HTTP tetapi dapat diperluas melalui header dan kontrak data adalah satu-satunya perubahan yang dapat merusak klien, namun dengan menggunakan metadata dalam kontrak pesan, server dapat secara dinamis mengirimkan versi yang sesuai dari kontrak data ke klien.
Darrel Miller

11

REST dimulai, sepengetahuan saya, oleh disertasi Roy Fielding, Gaya Arsitektur dan Desain Arsitektur Perangkat Lunak Berbasis Jaringan , yang patut dibaca jika Anda belum melihatnya.

Di bagian atas disertasi adalah kutipan:

Hampir semua orang merasa damai dengan alam: mendengarkan gelombang laut di tepi pantai, di tepi danau yang tenang, di padang rumput, di atas ombak yang tertiup angin. Suatu hari, ketika kita telah mempelajari cara abadi lagi, kita akan merasakan hal yang sama tentang kota-kota kita, dan kita akan merasakan kedamaian di dalamnya, seperti yang kita lakukan hari ini saat berjalan di tepi laut, atau berbaring di rerumputan yang panjang. padang rumput.

- Christopher Alexander, The Timeless Way of Building (1979)

Dan itu benar-benar merangkumnya di sana. REST dalam banyak hal lebih elegan.

SOAP adalah protokol di atas HTTP, jadi SOAP melewati banyak konvensi HTTP untuk membangun konvensi baru dalam SOAP, dan dalam beberapa hal berlebihan dengan HTTP. HTTP, bagaimanapun, lebih dari cukup untuk mengambil, mencari, menulis, dan menghapus informasi melalui HTTP, dan itulah sebagian besar dari REST. Karena REST dibangun dengan HTTP dan bukan di atasnya, itu juga berarti bahwa perangkat lunak yang ingin berintegrasi dengannya (seperti browser web) tidak perlu memahami SOAP untuk melakukannya, hanya HTTP, yang harus paling banyak dipahami secara luas dan terintegrasi-dengan protokol yang digunakan pada saat ini.


SOAP didefinisikan kembali pada tahun 1998. Berapa banyak "konvensi" HTTP yang merupakan konvensi saat itu?
John Saunders

Menurut w3.org/Protocols/HTTP/1.0/spec.html HTTP ini telah digunakan sejak tahun 1990. Lalu kenapa ? Kita semua tahu satu-satunya alasan SOAP menggunakan http adalah karena port 80 kemungkinan besar terbuka di firewall. Microsoft tidak akan membuat kesalahan DCOM lagi.
Darrel Miller

1
" REST dibuat dengan HTTP, bukan di atasnya " +1. Seluruh utas ini sangat membantu bagi saya untuk memahami validitas menggunakan REST melalui SOAP dan sebaliknya.
Chris22

9

Dari sini :

Keuntungan REST:

  • Ringan - tidak banyak markup xml ekstra
  • Hasil yang Dapat Dibaca Manusia
  • Mudah dibuat - tidak perlu toolkit

Lihat juga ini :

Agar adil, REST bukanlah solusi terbaik untuk setiap layanan Web. Data yang perlu diamankan tidak boleh dikirim sebagai parameter di URI. Dan data dalam jumlah besar, seperti yang terdapat dalam pesanan pembelian mendetail, dapat dengan cepat menjadi rumit atau bahkan melampaui batas dalam URI. Dalam kasus ini, SOAP memang merupakan solusi yang solid. Tetapi penting untuk mencoba REST terlebih dahulu dan menggunakan SOAP hanya jika diperlukan. Ini membantu menjaga pengembangan aplikasi tetap sederhana dan dapat diakses.


4
Komentar kontra tidak sepenuhnya benar. Dengan memindahkan parameter dari URI ke dalam tubuh, ini masih tidak aman. Gunakan SSL untuk keamanan. Selain itu, bila data di uri bisa sangat panjang, Anda diperbolehkan menggunakan posting dan memasukkannya ke dalam body. Sebagian besar bahasa sisi server menggabungkan data dari parameter URI dan parameter POST, jadi tidak perlu ada perubahan pada server.
Emil Ivanov

1
@Emil - Ingatlah bahwa SSL tidak selalu tersedia. Beberapa orang menginginkan keamanan berbasis pesan dan bukan keamanan berbasis tingkat transportasi. Dan sejauh menggunakan badan POST ... POST adalah salah satu kata kerja yang digunakan untuk memproses permintaan REST. Anda tidak dapat selalu menggunakannya kembali untuk memenuhi kebutuhan Anda.
Justin Niessner

1
Kontra besar: tidak ada bahasa "deskripsi" standar seperti WSDL untuk layanan SOAP - setiap layanan REST mungkin atau mungkin tidak didokumentasikan, dan kualitas dokumentasi sangat berbeda dari penawaran layanan yang lain .....
marc_s

3
@Marc_s Jika REST dilakukan dengan benar, tidak perlu "bahasa deskripsi" seperti WSDL. Jenis media yang digunakan memang perlu didokumentasikan, tetapi tidak boleh ada dokumentasi yang memasangkan titik akhir ke jenis media.
Darrel Miller

@Darrel: Maaf, saya tidak membeli omong kosong "tanpa deskripsi bahasa". Meskipun jenis dokumen didokumentasikan, mereka juga perlu dijelaskan. Selain itu, beberapa orang benar-benar suka mendesentralisasikan konten menjadi objek dalam bahasa pemrograman. Dalam hal ini, sangat berguna untuk memiliki definisi yang dapat dibaca mesin tentang apa yang dapat dikirim dan diterima layanan, sehingga alat Anda dapat membuat kelas yang sesuai, dan kode serialisasi.
John Saunders

8

Saya dapat dengan aman mengatakan saya telah menghabiskan banyak waktu untuk memahami ini sebagai pemula, tetapi ini adalah tautan terbaik untuk memulai dengan REST dari awal! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

Hanya untuk menarikmu masuk,

Pikirkan tentang apa itu "layanan web tradisional". Ini adalah antarmuka dengan "metode" yang terbuka. Klien mengetahui nama metode, masukan dan keluaran dan karenanya dapat memanggil mereka.

Sekarang bayangkan sebuah antarmuka yang tidak mengekspos "metode". Sebaliknya, itu mengekspos "objek". Jadi saat klien melihat antarmuka ini, yang dilihatnya hanyalah satu atau lebih "objek". "Sebuah objek" tidak memiliki masukan dan keluaran - karena "ia tidak melakukan apa-apa". Ini adalah kata benda, bukan kata kerja. Ini adalah "sesuatu", bukan "tindakan".

Misalnya, pikirkan layanan web tradisional yang menyediakan kondisi cuaca saat ini jika Anda menyediakannya dengan kota. Ini mungkin memiliki metode web seperti GetWeatherInfo () yang mengambil kota sebagai masukan dan menyediakan data cuaca sebagai keluaran. Sejauh ini mudah bagi Anda untuk memahami bagaimana klien akan menggunakan layanan web ini.

Sekarang bayangkan, di tempat layanan web di atas, ada yang baru yang menampilkan kota sebagai objek. Jadi, saat Anda melihatnya sebagai klien, alih-alih GetWeatherInfo (), Anda melihat New York, Dallas, Los Angeles, London, dan seterusnya. Dan kota-kota ini tidak memiliki metode khusus aplikasi yang bergantung padanya - mereka tampaknya seperti gas lembam - mereka sendiri tidak bereaksi.

Anda pasti berpikir - baik, bagaimana hal itu membantu Anda, sebagai klien, untuk mengetahui cuaca Dallas? Kami akan membahasnya dalam beberapa saat.

Jika semua yang Anda dapatkan dari layanan web adalah "sekumpulan objek", jelas Anda memerlukan cara untuk "menindaklanjutinya". Objek itu sendiri tidak memiliki metode untuk Anda panggil, jadi Anda memerlukan serangkaian tindakan yang dapat Anda terapkan ke objek ini. Dengan kata lain, Anda perlu "menerapkan kata kerja ke kata benda". Jika Anda melihat sebuah objek, misalnya apel, yang merupakan "kata benda", Anda dapat menerapkan "kata kerja" seperti makan ke benda itu. Tapi tidak semua kata kerja bisa diterapkan ke semua kata benda. Seperti, Anda bisa mengendarai mobil, tetapi tidak bisa mengendarai televisi.

Jadi, jika layanan web hanya mengekspos objek, dan Anda ditanya - ya, mari kita sekarang merancang beberapa tindakan atau kata kerja standar yang "semua klien dapat menerapkan ke semua objek yang mereka lihat", ...


Lalu apa keuntungan memiliki objek daripada metode?
Soumya Rauth

4

Berikut beberapa ide:

  • REST membatasi layanan Anda untuk menggunakan antarmuka yang seragam. Anda tidak perlu membuang waktu untuk melamun (atau berdebat) tentang semua kemungkinan cara kerja layanan Anda - Anda dapat langsung bekerja mengidentifikasi sumber daya di sistem Anda. Ternyata menjadi pekerjaan besar itu sendiri, tapi untungnya masalahnya cenderung jauh lebih baik didefinisikan.
  • Dengan sumber daya, asosiasi mereka, dan representasi mereka, sangat sedikit yang harus dilakukan dalam mengimplementasikan layanan Anda karena banyak keputusan telah dibuat untuk Anda.
  • Sistem Anda akan terlihat sangat mirip dengan sistem RESTful lainnya; kurva pembelajaran untuk rekan satu tim, mitra, dan klien akan berkurang.
  • Anda akan memiliki kosakata umum untuk mendiskusikan masalah desain dengan pengembang lain, dan bahkan dengan mereka yang kurang berpikiran teknis (seperti pelanggan).
  • Seperti yang dikatakan Darrel, karena Anda menggunakan hypertext-driven desain yang , layanan Anda mempersempit ruang lingkup penggandengan menjadi hanya satu hal - jenis media. Ini membantu Anda sebagai pengembang karena perubahan pada sistem Anda terdapat dalam pita kontak yang sempit. Ini membantu klien Anda karena lebih sedikit perubahan yang akan merusak kode mereka.
  • Hampir setiap masalah yang mungkin Anda miliki dalam mengimplementasikan REST dapat diselesaikan dengan mengekspos resource baru atau memikirkan ulang model resource Anda. Fokus ini, IMO, merupakan pendorong produktivitas yang besar.

Intinya, REST menghapus banyak keputusan desain dan implementasi yang paling memakan waktu dan kontroversial dari alur kerja tim Anda. Ini mengalihkan perhatian Anda dari menerapkan layanan ke mendesainnya . Dan itu melakukannya tanpa menumpuk gobbledygook ke protokol HTTP.


@ John Jika saya menjalankan VS dan membuat proyek WCF dan membuat antarmuka dengan atribut [ServiceContract], saya dapat menambahkan panggilan metode apa pun yang saya suka. CreateCustomer (), MakeOrder (), ConfirmOrder (), VerifyOrder (), SubmitOrder (), CheckStockAvailability (), CancelOrder () Dari metode tersebut, dapatkah Anda memberi tahu saya urutan apa yang harus saya gunakan untuk memproses pesanan? Bisakah Anda memberi tahu saya kapan saya diizinkan untuk menelepon CancelOrder ()? Haruskah saya memeriksa ketersediaan sebelum mengonfirmasi pesanan? Haruskah saya memverifikasi pesanan sebelum memeriksa ketersediaan? Antarmuka ini sepertinya tidak konsisten dengan yang melakukan penggajian.
Darrel Miller

1
@Darrel: Saya tidak melihat bagaimana REST membantu menyelesaikan ini. Apakah MakeOrdermemberikan URL untuk ConfirmOrderdan CancelOrder? Apakah klien belum mengetahui cara memanggil layanan, melainkan perlu menggunakan data-driven?
John Saunders

1
@John Tepat. Klien tahu bahwa url ConfirmOrder dan url CancelOrder mungkin disediakan untuk itu, tetapi klien tidak tahu seperti apa tampilan url tersebut dan hanya akan mengikuti mereka jika disediakan. Anda menyebutnya data-driven, Roy menyebutnya Hypermedia sebagai Engine of Application State.
Darrel Miller

@ Darrel: Saya rasa saya belum pernah melihat layanan bisnis penting di mana saya ingin menentukan apa yang harus dihubungi selanjutnya berdasarkan URL apa yang saya berikan dari panggilan sebelumnya.
John Saunders

1
@JohnSaunders: itu karena panggilan REST bukan tentang panggilan metode, tetapi transisi status (pikirkan mesin status). Dalam keadaan tertentu, server RESTful akan menentukan transisi status yang valid dan pengguna atau agen pengguna memilih transisi yang ingin diikuti.
Lie Ryan

4

Sebagian besar jawaban "pro" tentang REST tampaknya berasal dari orang-orang yang belum pernah mengembangkan layanan web atau klien SOAP menggunakan lingkungan yang menyediakan alat yang sesuai untuk tugas tersebut. Mereka mengeluh tentang masalah yang belum pernah saya temui, menggunakan Visual Studio .NET dan Pengembang Web Rasional IBM. Saya kira jika Anda harus mengembangkan layanan web atau klien dalam bahasa scripting, atau bahasa lain dengan sedikit atau tanpa dukungan alat, ini adalah keluhan yang valid.

Saya juga harus mengakui bahwa beberapa poin "pro" terdengar seperti hal-hal yang mungkin benar-benar benar - tetapi saya belum pernah melihat contoh yang menggambarkan nilainya. Secara khusus, saya akan sangat menghargai jika seseorang akan mengirim komentar yang berisi tautan ke contoh yang baik dari layanan web REST. Ini harus salah satu yang menggunakan beberapa tingkat sumber daya, mungkin dalam hierarki, dan yang menggunakan jenis media dengan benar. Mungkin jika saya melihat contoh yang baik, saya akan mengerti, dalam hal ini, saya akan kembali ke sini dan mengakuinya.


Contoh terbaik yang dapat dilihat oleh publik hingga saat ini adalah Sun Cloud API. Berikut adalah panduan kenai.com/projects/suncloudapis/pages/… Hanya untuk memenuhi syarat pengalaman saya dengan SOAP. Saya telah membangun, dan masih mendukung, layanan web ASMX menggunakan Pabrik Perangkat Lunak Layanan Web Microsoft dari grup Pola dan Praktik. Saya telah membangun layanan berbasis WCF menggunakan rilis berikutnya dari pabrik perangkat lunak yang sama. Saya juga menggunakan System.ServiceModel.Web WCF sejak pertama kali dirilis dengan Biztalk Services SDK pada Mei 2007.
Darrel Miller

1
John- salah satu contoh rest API adalah Amazon. Mereka memiliki @SOAP dan REST API. Hal ini mungkin berguna untuk Anda- docs.amazonwebservices.com/AmazonS3/latest/...
RichardOD

3

Untuk menambahkan sedikit putaran biasa pada jawaban yang sudah diberikan alasan kami menggunakan layanan REST di mana saya berada adalah bahwa jika Anda tahu Anda dapat memberikan URL kepada mitra bisnis dan tahu mereka akan menerima, sebagai gantinya, lempengan XML yang ditata dengan baik tidak peduli apakah mereka bekerja di .Net xx, PHP, Python, Java, Ruby atau entah apa itu sangat mengurangi sakit kepala.

Ini juga berarti bahwa di sisi non-teknologi, staf penjualan kami dapat membual tentang API serbaguna kami kepada orang-orang tanpa takut terlihat seperti muppets lengkap.

Terlepas dari manfaat teknis, apa pun yang mudah bagi non-teknisi untuk menjelaskan, mendemonstrasikan, dan merasa percaya diri adalah hal yang baik. SOAP, meskipun sama kerennya untuk teknisi jauh lebih sulit didekati oleh non-teknisi dan oleh karena itu tidak mudah untuk "menjual".

Saya cenderung memperhatikan bahwa hal-hal yang bukan teknisi bisa membuat kepala mereka bulat cenderung melekat. Jadi saya ragu REST sebagai teknik yang rentan seperti SOAP terhadap keinginan mode.

Tetapi semua hal tentang tidak menempatkan apa pun dalam layanan REST yang harus dikunci adalah benar ganda jika hanya karena teknologinya sangat mudah dipahami oleh orang-orang yang tidak begitu berpikiran teknis.


3

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

Dalam banyak hal, World Wide Web sendiri, berdasarkan HTTP, dapat dilihat sebagai arsitektur berbasis REST. Aplikasi RESTful menggunakan permintaan HTTP untuk mengirim data (membuat dan / atau memperbarui), membaca data (misalnya membuat kueri), dan menghapus data. Jadi, REST menggunakan HTTP untuk keempat operasi CRUD (Buat / Baca / Perbarui / Hapus).

REST adalah alternatif ringan untuk mekanisme seperti RPC (Remote Procedure Calls) dan Web Services (SOAP, WSDL, et al.). Nanti, kita akan melihat betapa REST jauh lebih sederhana.

Meskipun sederhana, REST memiliki fitur lengkap; pada dasarnya tidak ada yang dapat Anda lakukan di Layanan Web yang tidak dapat dilakukan dengan arsitektur RESTful. REST bukanlah "standar". Tidak akan pernah ada rekomendasi W3C untuk REST, misalnya. Dan meskipun ada kerangka kerja pemrograman REST, bekerja dengan REST sangat sederhana sehingga Anda sering dapat "menggulung milik Anda sendiri" dengan fitur pustaka standar dalam bahasa seperti Perl, Java, atau C #.


" Dalam banyak hal, World Wide Web itu sendiri, berdasarkan HTTP, dapat dilihat sebagai arsitektur berbasis REST. Aplikasi RESTful menggunakan permintaan HTTP untuk mengirim data (membuat dan / atau memperbarui), membaca data (misalnya membuat kueri), dan menghapus data. Jadi, REST menggunakan HTTP untuk keempat operasi CRUD (Buat / Baca / Perbarui / Hapus). "Ini adalah contoh praktis lain yang bagus untuk saya ambil dari posting ini. Terima kasih.
Chris22
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.