Pro dan Kontra dari RESTful architecture [closed]


20

Diskusi yang paling umum yang saya lihat mengenai pro dan kontra dari REST cenderung membingkai diskusi itu relatif terhadap SOAP. Saya juga tidak punya pengalaman. Saat ini saya dihadapkan pada suatu keputusan yang sulit saya evaluasi untuk kurangnya pengalaman saya. Saya mulai mengembangkan aplikasi yang memiliki beberapa komponen - terutama aspek administratif yang memungkinkan pemilik untuk mengelola beberapa situs - dan antarmuka pengguna yang menghadap publik yang memungkinkan pengguna untuk berinteraksi dengan data yang disimpan pada host. Saya perlu mengevaluasi implikasi yang memungkinkan bagian yang terakhir di-host di mana saja dan berkomunikasi dengan yang pertama melalui arsitektur RESTful - atau menuntut bahwa kedua komponen berada di host yang sama. Apa implikasi utama dari pengembangan arsitektur RESTful, khususnya yang berkaitan dengan kapasitasnya dalam bidang-bidang berikut:

1: Keamanan 2: Kinerja 3: Kompleksitas antarmuka

EDIT: Melihat beberapa jawaban untuk pertanyaan ini - saya harus mengklarifikasi. Saya tidak mencari perbandingan dengan SOAP - melainkan gambaran umum aplikasi REST vs aplikasi di mana semua komponen berada pada satu host. (terima kasih atas jawaban itu!)


3
Sarankan buka kembali. Pertanyaannya adalah umum dan jelas dengan cakupan jawaban yang masuk akal.
minghua

Jawaban:


13

Mengingat area-area itu, saya bisa memberikan gambaran kasar, tetapi saya tidak bisa menarik kesimpulan untuk Anda. Ada dua bidang utama di mana kedua protokol berbeda:

  • Format pesan
  • Penemuan layanan

Format pesan paling mudah dipahami. Kemasan SOAP untuk permintaan dan respons cukup berat. Ada amplop SOAP yang berisi bagian kepala dan bagian tubuh. Header dapat digunakan oleh beberapa filter dalam rantai permintaan untuk melakukan semacam identifikasi, otorisasi, dll. Namun, XML mahal untuk diurai, yang menghasilkan penalti tertentu untuk skalabilitas sistem Anda. Seberapa besar tergantung pada lapisan pemrosesan SOAP di tumpukan Anda.

Penemuan layanan adalah tempat Anda mungkin akan memiliki pertengkaran paling banyak. REST pada dasarnya memberikan titik akhir yang dapat diprediksi , dan konten permintaan adalah permintaan HTTP sederhana. Keuntungannya adalah tidak ada overhead tambahan, dan pengguna akhir dapat menebak bagaimana melakukan apa yang mereka butuhkan begitu mereka memahami struktur URL situs Anda. Tentu saja, orang yang sadar keamanan yang naif akan melihat itu sebagai kelemahan. Lagipula, dengan SOAP, Anda harus mengonsumsi WSDL untuk mengetahui titik akhir. Tentu saja, dengan SOAP Anda diberi seluruh format pesan sehingga Anda dapat membuat lebih banyak serangan yang ditargetkan.

Dipecah berdasarkan kategori yang Anda berikan:

Keamanan

Tak satu pun secara inheren lebih aman daripada yang lain. Gunakan prinsip keamanan yang baik:

  • Enkripsi komunikasi
  • Pastikan Anda mengautentikasi dan mengotorisasi pengguna sebelum diproses
  • Kebiasaan pengkodean yang baik untuk menghindari serangan langsung
  • Dan itu hanya daftar pendek.

Ingat ketidakjelasan! = Keamanan.

Performa

Baik kinerja mentah dan skalabilitas akan masuk ke REST karena permintaan berikut protokol HTTP sederhana. Sebagian besar tumpukan SOAP menggunakan parsing SAX (parsing berbasis kejadian) yang sangat meningkatkan skalabilitas tumpukan SOAP, tetapi ada dampak yang terukur terhadap overhead. SOAP memiliki overhead pemrosesan HTTP normal selain XML parsing overhead. REST hanya memiliki overhead pemrosesan HTTP.

Kompleksitas

Dari perspektif sistem, REST menang. Ada lebih sedikit bagian yang bergerak, rantai permintaan yang lebih ramping, dll. Itu berarti lebih mudah untuk membuatnya dapat diandalkan.

Dari perspektif programmer, SOAP dapat menang jika IDE atau framework yang Anda gunakan memberikan dukungan yang baik untuk itu. Pada dasarnya, dengan REST, tanggung jawab ada pada Anda untuk melakukan pekerjaan preprocessing (otentikasi / otorisasi / dll) sementara dengan SOAP banyak yang dapat diselesaikan dengan rantai pemrosesan yang dapat dicolokkan.

Preferensi saya

Saya sangat nyaman dengan permintaan HTTP, dan saya tahu cara kerja web. Akibatnya, pendekatan REST lebih disukai bagi saya. Namun, saya tahu bahwa beberapa klien saya merasa tidak nyaman dengan itu. Mereka telah membaca beberapa artikel industri mengecam keamanan REST vs SOAP, dll. Intinya adalah bahwa tidak ada pendekatan yang menjamin keamanan. Ada pada Anda untuk memastikan aplikasi seaman yang dibutuhkan. Jelas, aplikasi web sosial tidak menuntut (atau menginginkan) keamanan sebanyak bank atau sistem pemerintah. Banyak tumpukan SOAP menyertakan prosesor yang dapat Anda pasang untuk memberikan kemiripan keamanan, tetapi masih merupakan tanggung jawab Anda untuk mencari dan meletakkannya di tempat.


1
+1 untuk jawaban terinci. Untuk implementasi Java JAX-RS yang baik gunakan RESTEasy. Digabungkan dengan layanan web JAXB, tiba-tiba menjadi sepele.
Gary Rowe

2
"REST pada dasarnya memberikan titik akhir yang dapat diprediksi, dan isi dari permintaan adalah permintaan HTTP sederhana. Manfaatnya adalah tidak ada overhead tambahan, dan pengguna akhir dapat menebak bagaimana melakukan apa yang mereka butuhkan begitu mereka memahami Struktur URL situs Anda. " Sebenarnya, itu berlawanan dengan batasan HATEOAS REST ("Hypermedia sebagai Engine of Application State") jika Anda berbicara REST dengan benar. Ada segmen advokat REST yang akan memberi Anda hukuman mati karena menyiratkan bahwa komposisi URL adalah aspek dari REST. Saya tidak merasakannya dengan kuat tetapi banyak orang lain yang merasakannya.
MikeSchinkel

1
Namun sifat endpoint yang dapat diprediksi membuatnya lebih mudah untuk merancang dan membangun aplikasi. CATATAN: kerangka kerja yang mendukung aplikasi REST memiliki pola URL yang konsisten, tetapi mereka tidak selalu konsisten dari kerangka ke kerangka kerja. Pola URL yang teratur itu hanyalah masalah konstruksi dan kenyamanan pemrograman. Pola URL yang Anda lihat di aplikasi Ruby on Rails serupa dalam tindakan yang didukung, tetapi namanya berbeda di ASP.NET MVC.
Berin Loritsch

Melakukan "desain dengan URL" adalah cara yang buruk untuk melakukan desain RESTful yang didorong oleh kerangka kerja karena mudah bagi kerangka kerja untuk melakukannya dengan cara itu. Namun, biasanya rusak yang Anda dapatkan dari perilaku CRUD normal.
Darrel Miller

12
  1. Keamanan: Gunakan HTTPS. Ini berlaku untuk keduanya.
  2. Kinerja: . REST lebih murah CPU (lebih sedikit parsing, marshalling, membuka bungkus). Juga, caching dengan REST adalah sepotong kue.
  3. Kompleksitas: REST menuntut lebih sedikit dalam hal pengaturan, hanya saja GET / POST. SOAP membutuhkan administrasi yang lebih banyak untuk dipelihara (wsdl dll), tetapi sedikit lebih mudah jika IDE Anda mendukungnya.

Saya pikir SOAP terlalu membengkak ketika Anda dapat melakukan hal yang sama dengan REST dan beberapa tipe konten / mime. Juga, SOAP membawa banyak overhead, karena sifat pembungkusnya dan fakta bahwa itu lebih umum dan tidak terbatas pada HTTP. SOAP tergoda untuk digunakan jika IDE Anda mendukungnya dengan benar dan Anda tidak ingin belajar HTTP. Tetapi bagi saya, REST jauh lebih mudah digunakan dan lebih ramah web.

Saat ini, ada API REST yang sangat baik untuk digunakan. Jika Anda ke Jawa, maka Jax-RS sangat keren. Bagi sebagian orang, ini seperti porno.


2
1 karena SOAP adalah kembung. SISA pasti cara untuk pergi. Dan tautan itu untuk JAX-RS menunjukkan alasannya.
Gary Rowe

1
Apakah ada tumpukan .Net REST yang bagus?
BlackICE


8

Saya pikir keuntungan terbesar dari REST adalah untuk keluar dari arsitektur RPC. REST memperlihatkan sumber daya, bukan proses. Itu memungkinkan Anda untuk membuat sistem yang terikat longgar, di mana perubahan, peningkatan, bahkan kegagalan satu bagian berdampak terbatas (negatif) pada bagian lain.

Sayangnya, penyalahgunaan REST yang umum adalah untuk mengekspos struktur data dalam Anda (dalam kasus terburuk, itu adalah CRUD dari database Anda, ugh). Itu membuatnya sangat sulit untuk melakukannya dengan aman. Penggunaan 'benar' adalah untuk mengekspos objek tingkat tinggi yang relevan dengan bagian dari sistem yang Anda tangani, dan secara bebas mengembalikan kode status kesalahan pada setiap inkonsistensi.

Bagian lain yang sering diabaikan dari REST adalah idempotensi sebagian besar kata kerja. Tidak hanya DAPATKAN, tetapi juga PUT dan DELETE harus hasil yang persis sama jika diterapkan sekali atau beberapa kali (Anda bebas mengembalikan 404 jika sudah dihapus, atau 'tidak ada perubahan' jika klien PUTting yang sama). Itu mengarah ke sistem yang kuat dan kurang saling ketergantungan interpretasi yang tepat dari semantik.


1
+1 untuk idempotensi. Saya pernah melihatnya sekali sebelumnya tetapi tidak bisa menemukannya sampai sekarang. Adakah yang tahu ada tutorial tentang desain yang tenang di pdf menyebutkannya?
minghua

3

Standar WS- * sebagian besar tentang menjalankan RPC melalui SOAP / HTTP. Jadi, semua pemikiran yang masuk ke CORBA dan J2EE dan pendahulunya sebagian besar telah pindah untuk melakukan hal-hal yang sama dalam XML. Ini berarti hal-hal seperti deklarasi tipe dan kontrak layanan, pertukaran metadata, keamanan deklaratif dll. Semua hal yang nyata "perusahaan". Terus terang bahkan di perusahaan, terus terang.

Orang yang membangun aplikasi web internet seperti Anda, hampir pasti akan lebih baik menggunakan arsitektur yang tenang. Hampir semua platform dapat mengkonsumsinya dan melakukannya secara sederhana dan tanpa khawatir tentang versi spek mana yang Anda gunakan dan segudang keanehan jenis konversi khusus-alat, dll.


Memang: pengalaman saya tentang standar WS- * adalah bahwa mereka adalah contoh mulia dari "standar" di mana setiap implementasi berbeda dan tidak kompatibel. Buat tetap sederhana, imho, untuk layanan yang menghadap publik, dan hanya gunakan SOAP untuk komunikasi pribadi antara sistem yang berjalan pada platform yang sama.
Carson63000

0

Hanya keuntungan besar dari SOAP dibandingkan implementasi REST saat ini adalah bahwa SOAP lebih mudah diolah - sebagian besar klien RESTful meminta saya untuk memahami antarmuka dan menulis semacam klien. Untuk SOAP, saya hanya menunjuk wsdl.exe dan menghasilkan kelas untuk saya.


1
Pernahkah Anda menulis alat introspeksi SOAP sendiri? Ini adalah pengalaman yang tidak menyenangkan yang akan mengalihkan Anda ke REST.
pydanny

1
Tidak, tetapi sebagian besar platform yang melihat SOAP telah mengatakan alat introspeksi dibangun. Jika saya melihat membangun satu atau beristirahat, saya akan melakukan hal REST.
Wyatt Barnett
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.