Apa perbedaan antara HTTP dan REST?

Setelah membaca banyak tentang perbedaan antara REST dan SOAP, saya mendapat kesan bahwa REST hanyalah kata lain untuk HTTP. Bisakah seseorang menjelaskan fungsi apa yang ditambahkan REST ke HTTP?

Catatan : Saya tidak mencari perbandingan REST versus SOAP.

Pembaruan : Terima kasih atas jawaban Anda. Sekarang menjadi jelas bagi saya bahwa REST hanyalah seperangkat aturan tentang cara menggunakan HTTP. Karenanya saya memposting tindak lanjut tentang apa manfaat dari kebaktian ini .

Catatan : Sekarang saya memahami arti REST; seperti yang dikatakan Emil Ivanov , REST berarti menggunakan HTTP sebagaimana seharusnya. Namun, saya tidak yakin apakah ini layak untuk jangka waktu sendiri, dan saya pasti tidak mendapatkan hype di sekitarnya.

Tidak, REST adalah cara HTTP harus digunakan .

Hari ini kami hanya menggunakan sedikit metode protokol HTTP - yaitu GETdan POST. Cara REST untuk melakukannya adalah dengan menggunakan semua metode protokol.

Misalnya, REST menentukan penggunaan DELETEuntuk menghapus dokumen (baik itu file, status, dll.) Di belakang URI, sedangkan, dengan HTTP, Anda akan menyalahgunakan GETatau POSTmeminta kueri ...product/?delete_id=22.

HTTP adalah protokol yang digunakan untuk komunikasi, biasanya digunakan untuk berkomunikasi dengan sumber daya internet atau aplikasi apa pun dengan klien browser web.

REST berarti bahwa konsep utama yang Anda gunakan saat mendesain aplikasi adalah Resource: untuk setiap tindakan yang ingin Anda lakukan, Anda perlu menentukan sumber daya yang biasanya Anda lakukan hanya operasi CRUD, yang merupakan tugas sederhana. untuk itu sangat nyaman untuk menggunakan 4 kata kerja yang digunakan dalam protokol HTTP terhadap 4 operasi CRUD (Get for Read, POST untuk CREATE, PUT untuk UPDATE dan DELETE untuk DELETE). itu tidak seperti konsep RPC (Remote Procedure Call) yang lebih lama, di mana Anda memiliki serangkaian tindakan yang ingin Anda lakukan sebagai hasil dari panggilan pengguna. jika Anda berpikir misalnya tentang cara menggambarkan facebook seperti pada posting, dengan RPC Anda dapat membuat layanan yang disebut AddLikeToPost dan RemoveLikeFromPost, dan mengelolanya bersama dengan semua layanan Anda yang terkait dengan posting FB, sehingga Anda tidak perlu membuat khusus objek untuk Suka. dengan REST Anda akan memiliki objek Suka yang akan dikelola secara terpisah dengan fungsi Hapus dan Buat. Ini juga berarti akan menggambarkan entitas terpisah di db Anda. itu mungkin terlihat seperti perbedaan kecil, tetapi bekerja seperti itu biasanya akan menghasilkan kode yang lebih sederhana dan aplikasi yang jauh lebih sederhana. dengan desain itu, sebagian besar logika aplikasi jelas dari struktur objek (model), tidak seperti RPC yang biasanya harus Anda tambahkan secara eksplisit lebih banyak logika.

merancang aplikasi RESTful biasanya jauh lebih sulit karena mengharuskan Anda untuk menggambarkan hal-hal rumit dengan cara yang sederhana. menggambarkan semua fungsi hanya menggunakan fungsi CRUD itu rumit, tetapi setelah melakukan itu hidup Anda akan jauh lebih sederhana dan Anda akan menemukan bahwa Anda akan menulis metode yang jauh lebih pendek.

Satu lagi yang menahan arsitektur REST adalah tidak menggunakan konteks sesi ketika berkomunikasi dengan klien (stateless), artinya semua informasi perlu memahami siapa klien dan apa yang dia inginkan diteruskan dengan pesan web. setiap panggilan ke suatu fungsi bersifat deskriptif sendiri, tidak ada percakapan sebelumnya dengan klien yang dapat dirujuk dalam pesan. karenanya klien tidak dapat memberi tahu Anda "beri saya halaman berikutnya" karena Anda tidak memiliki sesi untuk menyimpan apa halaman sebelumnya dan jenis halaman apa yang Anda inginkan, klien harus mengatakan "nama saya yuval, dapatkan saya halaman 2 dari posting tertentu di forum tertentu ". itu berarti sedikit lebih banyak data yang harus ditransfer dalam komunikasi, tetapi pikirkan perbedaan antara menemukan bug yang dilaporkan dari fungsi "get me next page" berlawanan dengan "

Tentu saja ada banyak lagi, tetapi menurut saya itu adalah konsep utama dalam satu sendok teh.

HTTP adalah protokol aplikasi. REST adalah seperangkat aturan, yang ketika diikuti, memungkinkan Anda untuk membangun aplikasi terdistribusi yang memiliki serangkaian kendala yang diinginkan.

Jika Anda mencari batasan REST paling signifikan yang membedakan aplikasi RESTful dari sembarang aplikasi HTTP, saya akan mengatakan batasan "deskripsi-diri" dan batasan hypermedia (alias Hypermedia sebagai Engine of Application State (HATEOAS)) adalah yang paling penting.

Kendala uraian-mandiri mengharuskan permintaan RESTful sepenuhnya deskriptif diri dalam maksud pengguna. Ini memungkinkan perantara (proksi dan cache) untuk bertindak berdasarkan pesan dengan aman.

Kendala HATEOAS adalah tentang mengubah aplikasi Anda menjadi web tautan di mana keadaan klien saat ini didasarkan pada tempatnya di web itu. Ini adalah konsep yang rumit dan membutuhkan lebih banyak waktu untuk menjelaskan daripada yang saya miliki saat ini.

Seperti yang saya pahami, REST memberlakukan penggunaan perintah HTTP yang tersedia karena seharusnya digunakan.

Sebagai contoh, saya bisa melakukan:

GET
http://example.com?method=delete&item=xxx

Tetapi dengan istirahat saya akan menggunakan metode permintaan "HAPUS", menghapus kebutuhan untuk parameter "metode" permintaan

DELETE
http://example.com?item=xxx

Tidak terlalu...

http://en.wikipedia.org/wiki/Representational_State_Transfer

REST awalnya dijelaskan dalam konteks HTTP, tetapi tidak terbatas pada protokol itu. Arsitektur RESTful dapat didasarkan pada protokol Layer Aplikasi lain jika mereka sudah menyediakan kosakata yang kaya dan seragam untuk aplikasi berdasarkan transfer status representasi yang bermakna. Aplikasi RESTful memaksimalkan penggunaan antarmuka yang sudah ada, terdefinisi dengan baik dan kemampuan built-in lainnya yang disediakan oleh protokol jaringan yang dipilih, dan meminimalkan penambahan fitur khusus aplikasi baru di atasnya.

http://www.looselycoupled.com/glossary/SOAP

(Protokol Akses Objek Sederhana) Standar untuk pesan layanan web. Berdasarkan XML, SOAP mendefinisikan format amplop dan berbagai aturan untuk menggambarkan isinya. Terlihat (dengan WSDL dan UDDI) sebagai salah satu dari tiga standar dasar layanan web, itu adalah protokol yang disukai untuk bertukar layanan web, tetapi tidak berarti satu-satunya; pendukung REST mengatakan bahwa itu menambah kompleksitas yang tidak perlu.

REST adalah cara spesifik untuk mendekati desain sistem besar (seperti web).

Ini adalah seperangkat 'aturan' (atau 'kendala').

HTTP adalah protokol yang mencoba mematuhi aturan-aturan itu.

REST = Transfer Negara Representasi

REST adalah seperangkat aturan, yang ketika diikuti, memungkinkan Anda untuk membangun aplikasi terdistribusi yang memiliki serangkaian kendala yang diinginkan.

REST adalah protokol untuk bertukar pesan (XML, JSON, dll) yang dapat menggunakan HTTP untuk mengirim pesan-pesan itu.

Fitur:

Ini adalah stateless yang berarti idealnya tidak ada koneksi yang harus dipertahankan antara klien dan server. Merupakan tanggung jawab klien untuk meneruskan konteksnya ke server dan kemudian server dapat menyimpan konteks ini untuk memproses permintaan klien selanjutnya. Misalnya, sesi yang dikelola oleh server diidentifikasi oleh pengidentifikasi sesi yang diteruskan oleh klien.

Keuntungan dari Statelessness:

1. Layanan Web dapat memperlakukan setiap panggilan metode secara terpisah.
2. Layanan Web tidak perlu mempertahankan interaksi klien sebelumnya.
3. Ini pada gilirannya menyederhanakan desain aplikasi.
4. HTTP sendiri merupakan protokol stateless seperti TCP dan karenanya RESTful Web Services bekerja secara lancar dengan protokol HTTP.

Kekurangan dari Statelessness:

1. Satu lapisan tambahan dalam bentuk tajuk perlu ditambahkan ke setiap permintaan untuk menjaga status klien.
2. Untuk keamanan, kami perlu menambahkan info tajuk ke setiap permintaan.

Metode HTTP yang didukung oleh REST:

DAPATKAN: / string / someotherstring Ini idempoten dan idealnya harus mengembalikan hasil yang sama setiap kali panggilan dilakukan

PUT: Sama seperti GET. Idempoten dan digunakan untuk memperbarui sumber daya.

POST: harus mengandung url dan isi yang digunakan untuk membuat sumber daya. Beberapa panggilan idealnya menghasilkan hasil yang berbeda dan harus membuat banyak produk.

HAPUS: Digunakan untuk menghapus sumber daya di server.

KEPALA:

Metode HEAD identik dengan GET kecuali bahwa server TIDAK HARUS mengembalikan tubuh pesan dalam respons. Informasi meta yang terkandung dalam header HTTP dalam menanggapi permintaan HEAD HARUS identik dengan informasi yang dikirim sebagai tanggapan terhadap permintaan GET.

PILIHAN:

Metode ini memungkinkan klien untuk menentukan opsi dan / atau persyaratan yang terkait dengan sumber daya, atau kemampuan server, tanpa menyiratkan tindakan sumber daya atau memulai pengambilan sumber daya.

Tanggapan HTTP

Buka di sini untuk semua tanggapan .

Berikut adalah beberapa yang penting: 200 - OK 3XX - Informasi tambahan diperlukan dari klien dan pengalihan url 400 - Permintaan buruk
401 - Tidak diizinkan untuk mengakses
403 - Terlarang
Permintaan itu valid, tetapi server menolak tindakan. Pengguna mungkin tidak memiliki izin yang diperlukan untuk sumber daya, atau mungkin memerlukan semacam akun.

404 - Tidak Ditemukan
Sumber daya yang diminta tidak dapat ditemukan tetapi mungkin tersedia di masa depan. Permintaan selanjutnya oleh klien diizinkan.

405 - Metode Tidak Diizinkan Metode permintaan tidak didukung untuk sumber daya yang diminta; misalnya, permintaan GET pada formulir yang mengharuskan data disajikan melalui POST, atau permintaan PUT pada sumber daya baca-saja.

404 - Permintaan tidak ditemukan
500 - Kegagalan Server Internal
502 - Kesalahan Gateway Buruk

HTTP adalah protokol komunikasi yang mengangkut pesan melalui jaringan. SOAP adalah protokol untuk bertukar pesan berbasis XML yang dapat menggunakan HTTP untuk mengirim pesan-pesan itu. Rest adalah protokol untuk bertukar pesan (XML atau JSON) apa pun yang dapat menggunakan HTTP untuk mengirim pesan-pesan itu.

HTTP is a contract, a communication protocol and REST is a concept, an architectural style yang dapat menggunakan HTTP, FTP atau protokol komunikasi lainnya tetapi banyak digunakan dengan HTTP.

REST implies a series of constraints about how Server and Client should interact. HTTP is a communication protocol with a given mechanism for server-client data transfer, ini paling umum digunakan dalam REST API hanya karena REST was inspired by WWW (world wide web) which largely used HTTPsebelum REST didefinisikan, jadi lebih mudah untuk menerapkan gaya REST API dengan HTTP.

There are three major constraints in REST (but there are more):

1. Interaksi antara server dan klien harus dijelaskan hanya melalui hypertext.

2.Server dan klien harus digabungkan secara longgar dan tidak membuat asumsi tentang satu sama lain. Klien hanya harus tahu titik masuk sumber daya. Data interaksi harus disediakan oleh server dalam respons.

3.Server tidak boleh menyimpan informasi tentang konteks permintaan. Permintaan harus independen dan idempoten (artinya jika permintaan yang sama diulang tanpa batas, hasil yang sama persis diambil)

Dan HTTP hanyalah protokol komunikasi (alat) yang dapat membantu untuk mencapai ini.

Untuk info lebih lanjut, periksa tautan ini:

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

REST tidak harus terikat dengan HTTP . Layanan web yang tenang hanya layanan web yang mengikuti arsitektur yang tenang.

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

Dari Anda tidak tahu perbedaan antara HTTP dan REST

Jadi arsitektur REST dan protokol HTTP 1.1 bersifat independen satu sama lain, tetapi protokol HTTP 1.1 dibangun untuk menjadi protokol ideal untuk mengikuti prinsip dan batasan REST. Salah satu cara untuk melihat hubungan antara HTTP dan REST adalah, bahwa REST adalah desain, dan HTTP 1.1 adalah implementasi dari desain itu.

REST APIs harus digerakkan oleh hypertext

Dari blog Roy Fielding, inilah serangkaian cara untuk memeriksa apakah Anda membuat HTTP API atau REST API:

Desainer API, harap perhatikan aturan berikut sebelum menyebut kreasi Anda API REST:

• REST API tidak boleh bergantung pada protokol komunikasi tunggal apa pun, meskipun pemetaannya yang berhasil ke protokol yang diberikan mungkin bergantung pada ketersediaan metadata, pilihan metode, dll. Secara umum, setiap elemen protokol yang menggunakan URI untuk identifikasi harus memungkinkan skema URI apa pun yang akan digunakan untuk kepentingan identifikasi itu. [Kegagalan di sini menyiratkan bahwa identifikasi tidak dipisahkan dari interaksi.]
• API REST tidak boleh mengandung perubahan apa pun pada protokol komunikasi selain dari mengisi atau memperbaiki detail bit yang kurang spesifik dari protokol standar, seperti metode PATCH HTTP atau bidang taut tautan. Solusi untuk implementasi yang rusak (seperti browser yang cukup bodoh untuk percaya bahwa HTML mendefinisikan set metode HTTP) harus didefinisikan secara terpisah, atau setidaknya dalam lampiran, dengan harapan bahwa solusi pada akhirnya akan usang. [Kegagalan di sini menyiratkan bahwa antarmuka sumber daya adalah objek-spesifik, bukan generik.]
• REST API harus menghabiskan hampir semua upaya deskriptifnya dalam mendefinisikan jenis media yang digunakan untuk mewakili sumber daya dan status aplikasi mengemudi, atau dalam mendefinisikan nama hubungan yang diperluas dan / atau mark-up yang memungkinkan hypertext untuk jenis media standar yang ada. Upaya apa pun yang digunakan untuk menjelaskan metode apa yang digunakan pada URI apa yang diminati harus sepenuhnya ditentukan dalam ruang lingkup aturan pemrosesan untuk jenis media (dan, dalam banyak kasus, sudah ditentukan oleh jenis media yang ada). [Kegagalan di sini menyiratkan bahwa informasi out-of-band mendorong interaksi bukannya hiperteks.]
• API REST tidak boleh mendefinisikan nama sumber daya tetap atau hierarki (penggabungan yang jelas antara klien dan server). Server harus memiliki kebebasan untuk mengontrol namespace mereka sendiri. Sebagai gantinya, izinkan server untuk menginstruksikan klien tentang cara membuat URI yang sesuai, seperti yang dilakukan dalam formulir HTML dan templat URI, dengan menetapkan instruksi tersebut dalam jenis media dan hubungan tautan. [Kegagalan di sini menyiratkan bahwa klien mengasumsikan struktur sumber daya karena informasi out-of band, seperti standar khusus domain, yang setara dengan data yang berorientasi pada penggabungan fungsional RPC].
• API REST seharusnya tidak memiliki sumber daya "diketik" yang signifikan bagi klien. Spesifikasi penulis dapat menggunakan tipe sumber daya untuk menggambarkan implementasi server di belakang antarmuka, tetapi jenis tersebut harus tidak relevan dan tidak terlihat oleh klien. Satu-satunya jenis yang signifikan bagi klien adalah jenis media representasi saat ini dan nama hubungan standar. [dito]
• API REST harus dimasukkan tanpa pengetahuan sebelumnya di luar URI awal (bookmark) dan sekumpulan jenis media terstandar yang sesuai untuk audiens yang dituju (yaitu, diharapkan dipahami oleh klien mana pun yang mungkin menggunakan API). Sejak saat itu, semua transisi status aplikasi harus didorong oleh pemilihan klien dari pilihan yang disediakan server yang hadir dalam representasi yang diterima atau tersirat oleh manipulasi pengguna dari representasi tersebut. Transisi dapat ditentukan (atau dibatasi oleh) pengetahuan klien tentang jenis media dan mekanisme komunikasi sumber daya, yang keduanya dapat ditingkatkan dengan cepat (misalnya, kode sesuai permintaan). [Kegagalan di sini menyiratkan bahwa informasi out-of-band mendorong interaksi bukannya hiperteks.]