REST vs RESTful vs layanan web "normal"

21

Saya sudah membaca beberapa definisi dan diskusi tentang REST dan / atau aplikasi RESTful, tapi saya masih tidak mengerti arti sebenarnya dari itu.

Saya biasanya bekerja dengan aplikasi yang mengambil data melalui GET atau mengirim data melalui POST ke beberapa layanan web (biasanya skrip PHP) yang kemudian mendapatkan data dari database atau menulis ke dalam database.

Sekarang, apakah ini aplikasi yang tenang? Jika tidak, apa yang akan menjadi aplikasi tenang? Apa perbedaan antara konsep RESTful dan konsep yang saya kerjakan sejauh ini? Tolong jelaskan melalui contoh.

Juga, seseorang berbicara tentang REST dan seseorang tentang aplikasi RESTful. Saya menemukan bahwa istilah REST mengacu pada konsep teoretis, sementara RESTful digunakan ketika kita berbicara tentang aplikasi tertentu. Apakah ini benar atau ada perbedaan nyata antara aplikasi REST dan RESTful?

— deviDave
sumber

1

Jika Anda dapat membuat semua Server Anda untuk menarik informasi dari parameter GET atau POST SAJA (sama sekali tidak ada yang disimpan secara lokal sebelum panggilan), maka Anda menerapkan REST dengan benar. Dengan kata lain, server memainkan peran model dalam MVC karena tidak terkontrol tetapi hanya menggunakan apa yang diberikan untuk melakukan beberapa tugas. Harapan itu menjelaskannya sedikit lebih baik.

— Neil

@Neil Saya di sisi lain - aplikasi seluler. Ini adalah klien yang menggunakan layanan web dan berkomunikasi dengannya melalui POST dan GET. Semua layanan web telah dibangun oleh orang lain dan yang saya lakukan hanyalah menggunakannya. Tapi terminologi membuatku bingung. Jadi, jika saya menggunakan saluran HTTP dan objek HttpGet / HttpPost, maka saya berurusan dengan aplikasi RESTful, kan?

— deviDave

Belum tentu. Tidak ada cara untuk mengetahui apakah ini aplikasi RESTful jika Anda tidak tahu bagaimana server dilakukan karena mungkin melanggar beberapa kendala. Yang mengatakan, itu mungkin tenang jika mengembalikan hasil yang konsisten.

— Neil

@Neil Oh, saya mengerti sekarang. Tenang dilakukan di server. Dan jika saya mengirim objek posting dengan permintaan (tidak setiap parameter secara individual) maka itu mungkin pendekatan REST. Sejauh klien (aplikasi seluler), tidak peduli apakah itu ISTIRAHAT atau tidak karena pengkodeannya sama. Apakah saya sudah benar?

— deviDave

2

RESTful adalah server dan klien, tetapi jika Anda hanya dapat melihat klien, maka Anda hanya dapat mengetahui apakah klien mengikuti kendala. Itu yang saya maksudkan. Yang saya maksud dengan REST adalah, jika Anda perlu login, Anda memposting nama pengguna dan kata sandi. Server memvalidasi login dan menyimpan kunci hash pengguna pada database dan mengembalikannya. Sekarang setiap kali Anda perlu melakukan operasi yang memerlukan login, Anda selalu melewati kunci hash pengguna. Server "lupa" bahwa ia login Anda, tetapi menggunakan hash pengguna untuk memvalidasi keadaan login Anda. Jika tidak TETAP, server akan ingat Anda masuk. Memahami perbedaannya?

— Neil

13

Atribut kunci dari aplikasi RESTful adalah: Semua komunikasi adalah melalui http GET, POST, PUT, DELETE DAN semua item ditangani melalui URL standar formulir http://your.site.com/salesapp/salesperson/0000001/detailsyaitu hanya URL murni tanpa parameter dll. URL mengidentifikasi hal yang DAPATKAN , POST, PUT, DELETE mengidentifikasi apa yang ingin Anda lakukan padanya.

Alasan utama untuk melakukan ini adalah bahwa Anda secara otomatis memiliki layanan tanpa kewarganegaraan yang dapat memuat seimbang, gagal melebihi dll. Dll

Kesederhanaan semata skema membuat antarmuka yang sangat bersih, benar-benar memisahkan klien dari implementasi back-end tertentu.

— James Anderson
sumber

Oh, sejauh ini saya belum menggunakan PUT atau DELETE (aplikasi seluler biasanya hanya GET dan POST), tetapi ini memang seperti apa yang telah saya lakukan dan sedang saya lakukan saat ini. Hanya saja klien tidak menggunakan istilah REST *, melainkan "layanan web" dan "skrip php"

— deviDave

2

James, bisakah Anda menjelaskan mengapa parameter kueri harus dihindari? Sebagai contoh, bagaimana saya menyatakan bahwa saya ingin sumber daya disaring dengan cara tertentu tanpa memperkenalkan hierarki yang salah?

— Gary Rowe

3

@GaryRowe: URL (tanpa parameter) mengidentifikasi sumber daya yang ingin Anda manipulasi. Anda masih dapat memiliki parameter tetapi ini tidak digunakan dalam mengidentifikasi sumber daya. Contoh GET pada direktori (URL yang diakhiri dengan a) harus mengembalikan daftar sumber daya dalam direktori. Parameter pada URL dapat digunakan untuk menentukan filter atau mengurutkan pesanan atau sesuatu seperti itu.

— Martin York

1

Terima kasih, Loki. James mungkin ingin mengedit jawabannya untuk mencerminkan bahwa karena tampaknya ia tidak mengizinkan parameter kueri digunakan dalam keadaan apa pun yang mungkin menyesatkan. Sebenarnya, ada pengamatan yang menarik bahwa daftar sumber daya dalam direktori itu sendiri merupakan sumber daya yang mengekspresikan konsep itu.

— Gary Rowe

REST tidak mengharuskan aplikasi untuk menjadi berbasis URL juga tidak mengharuskan Anda untuk memiliki kata kerja seperti GET, POST, DELETE, dll. Namun, untuk WebApp, URL adalah satu-satunya pilihan dan kata kerja yang disebutkan di atas.

— Nawaz

6

REST adalah singkatan dari Representational State Transfer. Jika perangkat lunak Anda sesuai dengan REST Constraints maka itu dianggap RESTful.

Benar, sekarang setelah saya tanpa malu-malu merobek dari Wikipedia, apa artinya ini? Ini secara efektif berarti menggunakan perintah HTTP inbuilt seperti GET, POST, PUT, DELETE dan beberapa lainnya yang lebih jarang untuk berkomunikasi bolak-balik antara klien dan server.

Apa yang Anda lakukan terdengar seperti aplikasi RESTFul. Namun, ada perbedaan besar antara layanan web RESTFul yang dirancang dengan baik dan bertumpukan. Misalnya kode PHP di ujung GET yang lain dapat melakukan perubahan status, yang akan dianggap salah karena GET dipandang sebagai operasi hanya baca. Ada perbedaan halus antara bagaimana POST (baru) dan PUT (ganti) digunakan juga.

Artikel Wikipedia tentang ini sebenarnya sangat bagus, jadi saya akan berhenti di sini.

— Martijn Verburg
sumber

Sejauh ini, saya menggunakan GET (HttpGet) untuk mengambil konten dan POST (HttpPost) untuk memasukkan / mengubah konten database. Saya mengirim ini sebagai parameter ke HttpPost dan skrip PHP di server web mengubah parameter ini menjadi kode SQL. Apakah ini aplikasi tenang? Saya tertarik pada konsep, bukan pada seberapa baik script PHP telah dilakukan. Saya belum berhasil.

— deviDave

2

Saya akan menyelidiki penggunaan PUT dalam kasus di mana Anda mengganti konten, REST yang lebih idiomatis daripada selalu menggunakan POST.

— Martijn Verburg

Ya, dalam hal ini saya akan menggunakan PUT.

— deviDave

+1 untuk mencatat bahwa GET harus diimplementasikan dengan benar (yaitu idempoten). Kesalahan mendasar seperti itu di masa-masa awal.

— Gary Rowe

@deviDave Anda mungkin juga ingin melihat ke PATCH yang dirancang untuk memperbarui bagian dari sumber daya. Seperti yang ditunjukkan Martin dengan tepat PUT adalah untuk mengganti seluruh sumber daya.

— Gary Rowe

4

Sebelum melangkah lebih jauh, pertanyaan terkait ini dapat membantu Anda

Perbedaan antara REST dan RESTful hanyalah semantik. REST adalah gaya arsitektur yang diterapkan pada hubungan klien-server. RESTful hanyalah cara untuk memberi tahu klien Anda bahwa Anda menggunakan REST.

Banyak aplikasi web yang mengklaim sebagai RESTful, tetapi sebenarnya hanya sebagian yang sesuai dengan REST Constraints (sebagaimana Martijn Verburg juga merujuk dalam jawabannya). Saya hanya akan daftar di sini tapi saya sangat menyarankan Anda untuk membaca artikel:

Server klien
Cacheable
Sistem berlapis
Kode sesuai permintaan (opsional)

Karena Anda menyebutkan bahwa Anda bekerja di sisi klien, mungkin bermanfaat untuk melihat apa yang akan diberikan dan diharapkan arsitektur REST dari Anda sebagai klien yang terhubung. Meskipun REST bukan HTTP, protokol ini yang paling populer yang mendukung apa itu REST, jadi saya akan membingkai contoh saya di sekitar itu.

Klien Anda diharapkan untuk:

gunakan kata kerja HTTP (mis. GET, POST, PUT, DELETE, OPTIONS, PATCH) untuk melakukan operasi yang relevan
menawarkan Terima tajuk dan pahami tajuk Jenis-Konten (mis. Anda menerima beberapa XML yang belum pernah Anda lihat sebelumnya tetapi Anda dapat menggunakan XSD yang dirujuk untuk membuat model domain sisi-klien untuk disajikan kepada pengguna Anda)
ikuti tautan yang ditawarkan dalam Tipe-Konten yang Anda pahami (mis. dapatkan pengguna atau aplikasi Anda untuk menyimpulkan bahwa <link rel="pay" href="http://example.org/orders(1)/payment">dalam HTML menyatakan transisi keadaan untuk membuat sumber daya pembayaran melalui POST dengan badan yang berisi beberapa XML yang mewakili rincian pembayaran seperti nomor kartu kredit , jumlah dan sebagainya)
bereaksi dengan benar terhadap berbagai kode status HTTP

Jika berhasil di atas maka dapat dianggap sebagai klien REST, Anda mungkin ingin menyebutnya "aplikasi RESTful" tetapi itu lebih baik menyiratkan bahwa Anda menggunakan REST di sisi klien yang salah sehingga sebaiknya hindari syarat.

— Gary Rowe
sumber

3

RESTful berarti antarmuka adalah sekumpulan objek, yang dapat dibaca dan diperbarui (dan mungkin dihapus). Artinya tidak ada permintaan multi-parameter (hanya parameter adalah objek yang ingin Anda baca) dan hanya ada satu jenis operasi yang mengubah apa pun di server, mengunggah status baru.

Batasan ini memastikan bahwa semua permintaan idempoten (mengirimkannya beberapa kali tidak memiliki efek tambahan untuk mengirimnya sekali). Ini penting, karena jaringan dapat gagal kapan saja dan tidak mengirimkan permintaan atau tanggapan apa pun dan dengan permintaan idempoten Anda hanya mengirimnya lagi dan tidak perlu melakukan pemulihan yang rumit.

— Jan Hudec
sumber

Upvote untuk paragraf 1. Jadi ringkas. Terima kasih!

— deviDave

Satu hal lagi engkau, untuk melihat apakah aku sudah benar. Jika saya (aplikasi saya) adalah klien dari layanan REST, saya sebagai klien tidak menganggap jika layanan ini tenang atau tidak karena pengkodean saya selalu sama (httpget, httppost, dll.)? Prinsip ini penting hanya untuk pemilik script server / app?

— deviDave

REST adalah pedoman untuk merancang semantik antarmuka. Teknologi yang mendasari adalah HTTP apakah antarmuka tenang atau tidak (tapi lapisan lain seperti XML-RPC atau SOAP tidak relevan untuk antarmuka tenang), sehingga Anda selalu menggunakan yang sama httpget, httppost dll Tapi Anda menangani kegagalan jaringan berbeda.

— Jan Hudec

untuk add, SMTP adalah antarmuka tenang, meskipun menggunakan kata kerja yang berbeda dari GET, PUT dll dan protokol yang mendasari yang berbeda, konsep adalah sama - Anda mengirim idempoten kata kerja perintah berbasis server.

— gbjbaanb

Tidak semua permintaan REST idempoten. Misalnya, mengeluarkan POST beberapa kali akan menghasilkan banyak sumber daya baru.

— Gary Rowe

REST vs RESTful vs layanan web "normal" - sama atau tidak?