Rupanya, REST hanyalah seperangkat konvensi tentang cara menggunakan HTTP . Saya ingin tahu keuntungan apa yang diberikan oleh konvensi ini. Apakah ada yang tahu?

Saya tidak berpikir Anda akan mendapatkan jawaban yang baik untuk ini, sebagian karena tidak ada yang benar-benar setuju pada apa SISA adalah . The halaman wikipedia berat pada istilah-istilah dan cahaya pada penjelasan. Halaman diskusi layak untuk dibaca sekilas hanya untuk melihat seberapa banyak orang tidak setuju tentang ini. Sejauh yang saya tahu, REST berarti:

Alih-alih memiliki bernama secara acak setter dan getter URL dan menggunakan GETuntuk semua getter dan POSTuntuk semua setter, kami mencoba untuk memiliki URL mengidentifikasi sumber daya, dan kemudian menggunakan tindakan HTTP GET, POST, PUTdan DELETEuntuk melakukan hal-hal kepada mereka. Jadi, bukannya

GET /get_article?id=1
POST /delete_article   id=1

Anda akan melakukannya

GET /articles/1/
DELETE /articles/1/

Dan kemudian POSTdan PUTsesuai dengan operasi "buat" dan "perbarui" (tapi tidak ada yang setuju ke mana).

Saya pikir argumen caching yang salah, karena query string yang umumnya cache, dan selain itu Anda tidak benar-benar perlu untuk menggunakannya. Misalnya Django membuat sesuatu seperti ini sangat mudah, dan saya tidak akan mengatakan itu REST:

GET /get_article/1/
POST /delete_article/     id=1

Atau bahkan cukup sertakan kata kerja dalam URL:

GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/

Dalam hal ini GETberarti sesuatu tanpa efek samping, dan POSTberarti sesuatu yang mengubah data di server. Saya pikir ini mungkin sedikit lebih jelas dan lebih mudah, terutama karena Anda dapat menghindari semuanya PUT-vs- POST. Plus, Anda dapat menambahkan lebih banyak kata kerja jika mau, jadi Anda tidak terikat secara artifisial dengan apa yang ditawarkan HTTP. Sebagai contoh:

POST /hide/article/1/
POST /show/article/1/

(Atau apa pun, sulit untuk memikirkan contoh sampai terjadi!)

Jadi kesimpulannya, hanya ada dua keuntungan yang bisa saya lihat:

1. API web Anda mungkin lebih bersih dan lebih mudah dipahami / ditemukan.
2. Saat menyinkronkan data dengan situs web, mungkin lebih mudah menggunakan REST karena Anda bisa mengatakannya synchronize("/articles/1/")atau apa saja. Ini sangat tergantung pada kode Anda.

Namun saya pikir ada beberapa kerugian yang cukup besar:

1. Tidak semua tindakan mudah dipetakan ke CRUD (buat, baca / ambil, perbarui, hapus). Anda bahkan mungkin tidak berurusan dengan sumber daya tipe objek.
2. Ini upaya ekstra untuk keuntungan yang meragukan.
3. Kebingungan ke arah mana PUTdan di POSTmana. Dalam bahasa Inggris mereka mengartikan hal yang serupa ("Saya akan menaruh / memposting pemberitahuan di dinding.").

Jadi sebagai kesimpulan saya akan mengatakan: kecuali jika Anda benar-benar ingin melakukan upaya ekstra, atau jika layanan Anda memetakan dengan sangat baik untuk operasi CRUD, simpan REST untuk versi kedua API Anda.

Saya baru saja menemukan masalah lain dengan REST: Tidak mudah untuk melakukan lebih dari satu hal dalam satu permintaan atau menentukan bagian mana dari objek majemuk yang ingin Anda dapatkan. Ini sangat penting pada ponsel di mana waktu pulang-pergi dapat menjadi signifikan dan koneksi tidak dapat diandalkan. Sebagai contoh, misalkan Anda mendapatkan posting di timeline facebook. Cara SISA "murni" akan menjadi sesuatu seperti

GET /timeline_posts     // Returns a list of post IDs.
GET /timeline_posts/1/  // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....

Itu agak konyol. API Facebook adalah IMO yang sangat bagus, jadi mari kita lihat apa yang mereka lakukan:

Secara default, sebagian besar properti objek dikembalikan ketika Anda membuat kueri. Anda bisa memilih bidang (atau koneksi) yang ingin Anda kembalikan dengan parameter kueri "bidang". Misalnya, URL ini hanya akan mengembalikan id, nama, dan gambar Ben: https://graph.facebook.com/bgolub?fields=id,name,picture

Saya tidak tahu bagaimana Anda akan melakukan hal seperti itu dengan REST, dan jika Anda melakukannya apakah itu akan tetap dianggap sebagai REST. Saya pasti akan mengabaikan siapa pun yang mencoba memberi tahu Anda bahwa Anda seharusnya tidak melakukan itu (terutama jika alasannya adalah "karena itu bukan ISTIRAHAT")!

Sederhananya, REST berarti menggunakan HTTP seperti yang seharusnya.

Lihatlah disertasi Roy Fielding tentang REST . Saya pikir setiap orang yang melakukan pengembangan web harus membacanya.

Sebagai catatan, Roy Fielding adalah salah satu pendorong utama di belakang protokol HTTP, juga.

Untuk menyebutkan beberapa keuntungan:

• Sederhana.
• Anda dapat memanfaatkan cache HTTP dan server proxy dengan baik untuk membantu Anda menangani beban tinggi.
• Ini membantu Anda mengatur bahkan aplikasi yang sangat kompleks menjadi sumber daya sederhana.
• Ini memudahkan klien baru untuk menggunakan aplikasi Anda, bahkan jika Anda belum mendesainnya secara khusus untuk mereka (mungkin, karena mereka tidak ada ketika Anda membuat aplikasi Anda).

Sederhananya: NONE .

Jangan ragu untuk downvote, tapi saya masih berpikir tidak ada manfaat nyata dibandingkan HTTP non-REST. Semua jawaban saat ini tidak valid. Argumen dari jawaban yang paling banyak dipilih saat ini:

• Sederhana.
• Anda dapat memanfaatkan cache HTTP dan server proxy dengan baik untuk membantu Anda menangani beban tinggi.
• Ini membantu Anda mengatur bahkan aplikasi yang sangat kompleks menjadi sumber daya sederhana.
• Ini memudahkan klien baru untuk menggunakan aplikasi Anda, bahkan jika Anda belum mendesainnya secara khusus untuk mereka (mungkin, karena mereka tidak ada ketika Anda membuat aplikasi Anda).

1. Sederhana

Dengan REST Anda memerlukan lapisan komunikasi tambahan untuk skrip sisi-server dan sisi klien => ini sebenarnya lebih rumit daripada penggunaan HTTP non-REST.

2. Caching

Caching dapat dikendalikan oleh tajuk HTTP yang dikirim oleh server. REST tidak menambahkan fitur apa pun yang hilang di non-REST.

3. Organisasi

REST tidak membantu Anda mengatur berbagai hal. Ini memaksa Anda untuk menggunakan API yang didukung oleh perpustakaan sisi server yang Anda gunakan. Anda dapat mengatur aplikasi Anda dengan cara yang sama (atau lebih baik) ketika Anda menggunakan pendekatan non-REST. Misalnya, lihat perutean Model-View-Controller atau MVC .

4. Mudah digunakan / diimplementasikan

Tidak benar sama sekali. Itu semua tergantung pada seberapa baik Anda mengatur dan mendokumentasikan aplikasi Anda. REST tidak akan secara ajaib membuat aplikasi Anda lebih baik.

IMHO, keuntungan terbesar yang dimungkinkan REST adalah mengurangi penggabungan klien / server. Jauh lebih mudah untuk mengembangkan antarmuka REST dari waktu ke waktu tanpa merusak klien yang ada.

Dapat ditemukan

Setiap sumber daya memiliki referensi ke sumber daya lain, baik dalam hierarki atau tautan, sehingga mudah untuk menjelajah. Ini merupakan keuntungan bagi manusia yang mengembangkan klien, menyelamatkan dia dari terus berkonsultasi dengan dokumen, dan menawarkan saran. Ini juga berarti server dapat mengubah nama sumber daya secara sepihak (selama perangkat lunak klien tidak melakukan hardcode pada URL).

Kompatibilitas dengan alat lain

Anda dapat CURL jalan Anda ke bagian mana pun dari API atau menggunakan browser web untuk menavigasi sumber daya. Membuat debugging dan pengujian integrasi lebih mudah.

Nama Kata Kerja Standar

Memungkinkan Anda menentukan tindakan tanpa harus mencari kata-kata yang benar. Bayangkan jika OOP getter dan setter tidak distandarisasi, dan beberapa orang menggunakan retrievedan definesebagai gantinya. Anda harus menghafal kata kerja yang benar untuk setiap titik akses individu. Mengetahui hanya ada segelintir verba yang tersedia untuk mengatasi masalah itu.

Status Standar

Jika Anda GETsumber daya yang tidak ada, Anda dapat yakin untuk mendapatkan 404kesalahan di RESTful API. Kontras dengan API non-TENANG, yang mungkin kembali {error: "Not found"}terbungkus dalam Tuhan tahu berapa banyak lapisan. Jika Anda membutuhkan ruang ekstra untuk menulis pesan kepada pengembang di sisi lain, Anda selalu dapat menggunakan isi tanggapan.

Contoh

Bayangkan dua API dengan fungsi yang sama, satu mengikuti REST dan yang lainnya tidak. Sekarang bayangkan klien berikut untuk API tersebut:

Tenang:

GET /products/1052/reviews
POST /products/1052/reviews       "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10

HTTP:

GET /reviews?product_id=1052
POST /post_review?product_id=1052                  "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10

Sekarang pikirkan pertanyaan-pertanyaan berikut:

• Jika panggilan pertama dari masing-masing klien berhasil, seberapa yakin Anda bisa menjadi sisanya juga bekerja?

• Ada pembaruan besar pada API yang mungkin atau mungkin tidak mengubah titik akses tersebut. Berapa banyak dokumen yang harus Anda baca kembali?

• Bisakah Anda memprediksi kembalinya permintaan terakhir?

• Anda harus mengedit ulasan yang diposting (sebelum menghapusnya). Bisakah Anda melakukannya tanpa memeriksa dokumen?

Saya sarankan untuk melihat How to Explained REST milik Ryan Tomayko untuk My Wife

Sunting pihak ketiga

Kutipan dari tautan waybackmaschine:

Bagaimana dengan sebuah contoh. Anda seorang guru dan ingin mengelola siswa:

• kelas apa mereka,
• nilai apa yang mereka dapatkan,
• kontak darurat,
• informasi tentang buku yang Anda ajarkan, dll.

Jika sistem yang berbasis web, maka mungkin ada URL untuk masing-masing kata benda yang terlibat di sini: student, teacher, class, book, room, etc. ... Jika ada representasi yang dapat dibaca mesin untuk setiap URL, maka akan sepele untuk memasang alat baru ke sistem karena semua informasi itu dapat dikonsumsi dengan cara standar. ... Anda dapat membangun sistem di seluruh negeri yang dapat berbicara dengan masing-masing sistem sekolah untuk mengumpulkan nilai ujian.

Masing-masing sistem akan mendapatkan informasi dari satu sama lain menggunakan HTTP GET sederhana. Jika satu sistem perlu menambahkan sesuatu ke sistem lain, itu akan menggunakan HTTP POST. Jika suatu sistem ingin memperbarui sesuatu di sistem lain, ia menggunakan PUT HTTP. Satu-satunya yang tersisa untuk mencari tahu adalah seperti apa data itu seharusnya.

Saya akan menyarankan semua orang, yang mencari jawaban untuk pertanyaan ini, melalui "slideshow" ini .

Saya tidak bisa mengerti apa itu REST dan mengapa itu sangat keren, pro dan kontra, perbedaan dari SOAP - tapi tayangan slide ini sangat brilian dan mudah dimengerti, jadi sekarang jauh lebih jelas bagi saya, daripada sebelumnya.

Caching.

Ada manfaat lain yang lebih mendalam dari REST yang berputar di sekitar kemampuan berkembang melalui kopling longgar dan hiperteks, tetapi mekanisme caching adalah alasan utama Anda harus peduli tentang RESTful HTTP.

Ini ditulis dalam disertasi Fielding . Tetapi jika Anda tidak ingin banyak membaca:

• peningkatan skalabilitas (karena stateless, cache, dan kendala sistem berlapis)
• klien dan server dipisahkan (karena kendala antarmuka stateless dan seragam)
  • klien yang dapat digunakan kembali (klien dapat menggunakan browser REST umum dan semantik RDF untuk memutuskan tautan mana yang harus diikuti dan bagaimana menampilkan hasil)
  • klien yang tidak melanggar (klien hanya dipecah oleh perubahan semantik khusus aplikasi, karena mereka menggunakan semantik alih-alih beberapa pengetahuan khusus API)

• Berikan setiap "sumber daya" ID
• Tautkan berbagai hal bersama
• Gunakan metode standar
• Sumber daya dengan banyak representasi
• Berkomunikasi tanpa kewarganegaraan

Apakah mungkin untuk melakukan semuanya hanya dengan POST dan GET? Ya, apakah ini pendekatan terbaik? Tidak Memangnya kenapa? karena kami memiliki metode standar. Jika Anda berpikir lagi, akan mungkin untuk melakukan semuanya menggunakan GET .. jadi mengapa kita harus repot-repot menggunakan POST? Karena standar!

Misalnya, hari ini memikirkan model MVC, Anda dapat membatasi aplikasi Anda hanya untuk menanggapi jenis kata kerja tertentu seperti POST, GET, PUT dan DELETE. Bahkan jika di bawah tenda semuanya ditiru menjadi POST dan GET, tidak masuk akal untuk memiliki kata kerja yang berbeda untuk tindakan yang berbeda?

Penemuan jauh lebih mudah di REST. Kami memiliki dokumen WADL (mirip dengan WSDL di layanan web tradisional) yang akan membantu Anda untuk mengiklankan layanan Anda ke dunia. Anda dapat menggunakan penemuan UDDI juga. Dengan HTTP POST dan GET tradisional, orang mungkin tidak tahu permintaan pesan dan skema respons Anda untuk menelepon Anda.

Salah satu keuntungannya adalah, kita dapat memproses dokumen XML dan data XML yang tidak berurutan dari sumber berbeda seperti objek InputStream, URL, simpul DOM ...

@Timmmm, tentang hasil edit Anda:

GET /timeline_posts     // could return the N first posts, with links to fetch the next/previous N posts

Ini secara dramatis akan mengurangi jumlah panggilan

Dan tidak ada yang mencegah Anda merancang server yang menerima parameter HTTP untuk menunjukkan nilai bidang yang mungkin diinginkan klien Anda ...

Tapi ini detail.

Jauh lebih penting adalah kenyataan bahwa Anda tidak menyebutkan keuntungan besar dari gaya arsitektur REST (skalabilitas yang jauh lebih baik, karena status server yang tidak merata; ketersediaan yang jauh lebih baik, karena status server yang kewarganegaraan juga; penggunaan layanan standar yang jauh lebih baik, seperti caching untuk misalnya, ketika menggunakan gaya arsitektur REST; kopling yang jauh lebih rendah antara klien dan server, karena penggunaan antarmuka yang seragam; dll.)

Adapun komentar Anda

"Tidak semua tindakan mudah dipetakan ke CRUD (buat, baca / ambil, perbarui, hapus)."

: suatu RDBMS juga menggunakan pendekatan CRUD (SELECT / INSERT / DELETE / UPDATE), dan selalu ada cara untuk mewakili dan bertindak berdasarkan model data.

Mengenai hukumanmu

"Anda bahkan mungkin tidak berurusan dengan sumber daya tipe objek"

: desain yang tenang pada dasarnya adalah desain yang sederhana - tetapi ini TIDAK berarti bahwa mendesainnya sederhana. Apakah Anda melihat perbedaannya? Anda harus banyak berpikir tentang konsep-konsep yang akan diwakili dan ditangani oleh aplikasi Anda, apa yang harus dilakukan olehnya, jika Anda mau, agar dapat mewakili ini melalui sumber daya. Tetapi jika Anda melakukannya, Anda akan berakhir dengan desain yang lebih sederhana dan efisien.

Pertanyaan-string dapat diabaikan oleh mesin pencari.