Apa perlunya metode seperti GET dan POST dalam protokol HTTP?

Bisakah kita tidak mengimplementasikan protokol HTTP hanya dengan menggunakan tubuh permintaan dan badan tanggapan?

Sebagai contoh, URL akan berisi permintaan, yang akan dipetakan ke suatu fungsi tergantung pada bahasa pemrograman di sisi server mengatakan Servlet dan sebagai tanggapan HTML dan tanggapan JavaScript akan dikirim.

Mengapa protokol HTTP memiliki gagasan tentang metode?

Dari jawaban, saya mengerti mengapa konsep metode ada .. Ini mengarah ke pertanyaan terkait lainnya:

Misalnya dalam tautan penulisan gmail, permintaan dan data PUT / POST akan dikirim. Bagaimana browser mengetahui metode mana yang digunakan? Apakah halaman gmail yang dikirim oleh server menyertakan nama metode yang digunakan ketika memanggil gmail membuat permintaan? ketika kita memanggil www.gmail.com, itu harus menggunakan metode GET, bagaimana browser tahu bahwa metode ini digunakan?

PS : Saya tidak punya kredit yang cukup untuk mengomentari jawaban, jadi saya tidak bisa mengomentari banyak pertanyaan yang diajukan oleh orang-orang terkait dengan niat di balik pertanyaan ini.

Seperti yang beberapa jawaban katakan, kita dapat membuat pengguna baru pada metode DELETE, maka hal ini menimbulkan pertanyaan tentang maksud metode di dalam protokol http, karena pada akhirnya, itu benar-benar tergantung pada server fungsi apa yang mereka inginkan untuk memetakan URL ke . Mengapa klien harus memberi tahu server metode apa yang digunakan untuk URL.

Harap perhatikan bahwa pertanyaan telah diubah / diklarifikasi sejak jawaban ini pertama kali ditulis. Respons lebih lanjut untuk iterasi terbaru dari pertanyaan adalah setelah aturan horizontal kedua

Apa perlunya metode seperti GET dan POST dalam protokol HTTP?

Mereka, bersama dengan beberapa hal lain seperti format header, aturan untuk bagaimana header dan badan dipisahkan, membentuk dasar dari protokol HTTP

Bisakah kita tidak mengimplementasikan protokol HTTP hanya dengan menggunakan tubuh permintaan dan badan tanggapan?

Tidak, karena apa pun yang Anda buat tidak akan menjadi protokol HTTP

Sebagai contoh, URL akan berisi permintaan, yang akan dipetakan ke suatu fungsi tergantung pada bahasa pemrograman di sisi server mengatakan Servlet dan sebagai tanggapan HTML dan tanggapan JavaScript akan dikirim.

Selamat, Anda baru saja menemukan protokol baru! Sekarang, jika Anda ingin mengatur badan standar untuk mengemudi dan memeliharanya, mengembangkannya dll, itu bisa melampaui HTTP suatu hari

Saya menghargai ini sedikit sulit, tetapi tidak ada yang ajaib tentang internet, TCP / IP atau komunikasi yang terjadi antara server dan klien. Anda membuka koneksi dan mengirim beberapa kata ke bawah kabel, membentuk percakapan. Pembicaraan benar-benar harus mematuhi beberapa spesifikasi yang telah diratifikasi di kedua ujungnya jika permintaan harus dipahami dan respons yang masuk akal disampaikan. Ini tidak berbeda dengan dialog apa pun di dunia. Anda berbicara bahasa Inggris, tetangga Anda berbicara bahasa Mandarin. Semoga tangan Anda melambaikan tangan, menunjuk dan mengguncang tangan akan cukup untuk menyampaikan pesan Anda bahwa Anda tidak ingin dia memarkir mobilnya di depan rumah Anda.

Kembali ke internet, jika Anda membuka soket ke server web yang sesuai dengan HTTP dan kirim yang berikut ini:

EHLO
AUTH LOGIN

(Awal transmisi email SMTP) maka Anda tidak akan mendapatkan jawaban yang masuk akal. Anda dapat membuat klien yang sesuai dengan SMTP yang paling sempurna, tetapi server web Anda tidak akan berbicara dengannya karena percakapan ini adalah tentang protokol bersama - tidak ada protokol bersama, tidak ada sukacita.

Inilah sebabnya mengapa Anda tidak dapat mengimplementasikan protokol HTTP tanpa mengimplementasikan protokol HTTP; jika apa yang Anda tulis tidak sesuai dengan protokol, maka itu bukan protokol - itu adalah sesuatu yang lain, dan itu tidak akan berfungsi sebagaimana ditentukan dalam protokol

Jika kami menjalankan dengan contoh Anda sejenak; di mana klien menghubungkan dan hanya menyatakan sesuatu yang terlihat seperti URL .. Dan server memahaminya dan hanya mengirim sesuatu yang terlihat seperti HTML / JS (halaman web) maka yakin, itu bisa bekerja. Apa yang Anda simpan? Beberapa byte untuk tidak mengatakan GET? Sedikit lebih banyak tentang membuang header sial itu .. Server juga menyelamatkan beberapa - tetapi bagaimana jika Anda tidak dapat mengetahui apa yang mengirimi Anda? Bagaimana jika Anda meminta URL yang berakhir dengan JPEG, dan mengirimkan Anda beberapa byte yang membuat gambar, tetapi itu dalam PNG? PNG tidak lengkap pada saat itu. Kalau saja kita memiliki header yang mengatakan berapa banyak byte yang terjadiuntuk mengirim, maka kita akan tahu apakah jumlah byte yang kami terima sebenarnya seluruh file atau tidak. Bagaimana jika server gzip respons untuk menghemat bandwidth tetapi tidak memberi tahu Anda? Anda akan menghabiskan daya komputasi yang cukup besar untuk mencoba apa yang dikirim.

Pada akhirnya, kita perlu metainformation - informasi tentang informasi; kita membutuhkan tajuk; kita membutuhkan file untuk memiliki nama, ekstensi, tanggal yang dibuat. Kami membutuhkan orang-orang untuk berulang tahun, untuk mengatakan tolong dan terima kasih, dll - dunia penuh dengan protokol dan sedikit info tentang konteksnya sehingga kami tidak perlu duduk dan menyelesaikan semuanya dari awal sepanjang waktu. Biayanya sedikit ruang penyimpanan, tetapi mudah sepadan

Apakah menerapkan berbagai metode HTTP benar-benar diperlukan?

Dapat diperdebatkan, seseorang tidak harus mengimplementasikan seluruh protokol yang ditentukan, dan ini biasanya berlaku untuk apa pun. Saya tidak tahu setiap kata dalam bahasa Inggris; tetangga China saya juga seorang pengembang perangkat lunak tetapi dalam industri yang berbeda dan dia bahkan tidak tahu bahasa Mandarin untuk beberapa istilah yang digunakan dalam industri saya apalagi bahasa Inggris. Hal yang baik adalah, kita berdua dapat mengambil dokumen tentang implementasi HTTP, dia dapat menulis server dan saya dapat menulis klien, dalam berbagai bahasa pemrograman pada arsitektur yang berbeda, dan mereka masih bekerja karena mereka mematuhi protokol

Mungkin ada kasus bahwa tidak ada pengguna Anda yang akan mengeluarkan apa pun selain permintaan GET, tidak akan menggunakan koneksi persisten, mengirim apa pun selain JSON sebagai badan, atau perlu menerima apa pun selain teks / teks sehingga Anda dapat menulis server web yang benar-benar dikupas yang hanya memenuhi permintaan browser klien yang sangat terbatas. Tetapi Anda tidak bisa begitu saja memutuskan untuk menghapus aturan dasar yang membuat "beberapa teks mengirimkan soket" apa itu HTTP; Anda tidak dapat membuang gagasan dasar bahwa permintaan akan berupa string seperti:

VERB URL VERSION
header: value

maybe_body

Dan responsnya akan memiliki versi, dan kode status dan mungkin tajuk. Jika Anda mengubah semua itu - ini bukan HTTP lagi - ini sesuatu yang lain, dan hanya akan bekerja dengan sesuatu yang dirancang untuk memahaminya. HTTP sesuai definisi ini, jadi jika Anda ingin mengimplementasikannya, Anda harus mengikuti definisi tersebut

Memperbarui

Pertanyaan Anda telah sedikit berkembang, inilah beberapa respons terhadap apa yang Anda tanyakan:

Mengapa protokol HTTP memiliki gagasan tentang metode?

Secara historis Anda perlu menghargai bahwa banyak hal yang lebih tidak fleksibel dalam desain dan implementasinya, bahkan sejauh skrip tidak ada dan bahkan gagasan bahwa halaman dapat dinamis, dihasilkan dengan cepat dalam memori dan menekan soket sebagai gantinya menjadi file statis pada disk yang diminta oleh klien dan membaca dan menekan soket, tidak ada. Dengan demikian, web awal yang berpusat di sekitar gagasan tentang halaman statis yang berisi tautan ke halaman lain, semua halaman yang ada pada disk dan navigasi akan dilakukan oleh terminal yang sebagian besar membuat permintaan GET untuk halaman pada URL, server akan dapat memetakan url ke file di disk dan kirimkan. Ada juga anggapan bahwa jaringan dokumen yang terhubung satu sama lain dan ke tempat lain harus berkembang,

Itu memberikan beberapa konteks historis untuk metode-pada suatu waktu URL adalah bit tidak fleksibel, dan secara sederhana merujuk ke halaman pada disk sehingga metode ini berguna karena memungkinkan klien untuk menggambarkan niat apa yang dimiliki untuk file dan server akan memproses metode dengan berbagai cara. Sebenarnya tidak ada gagasan tentang url yang virtual atau digunakan untuk beralih atau memetakan dalam visi asli hiperteks (dan itu hanya teks) web

Saya tidak bermaksud jawaban ini menjadi dokumentasi dari catatan sejarah dengan tanggal dan referensi yang dikutip tentang kapan hal-hal mulai berubah - untuk itu Anda mungkin dapat membaca Wikipedia - tetapi cukup untuk mengatakan bahwa seiring waktu keinginan untuk web untuk lebih mengumpulkan momentum dan di setiap ujung koneksi server-klien peluang untuk menciptakan pengalaman multimedia yang kaya yang kami kembangkan. Browser mendukung proliferasi tag yang sangat besar untuk memformat konten, masing-masing berlomba untuk mengimplementasikan fitur kekayaan media yang harus dimiliki dan cara-cara baru untuk membuat sesuatu terlihat keren.

Scripting tiba di ujung klien dan plugins dan ekstensi browser, semua ditujukan untuk membuat browser menjadi pembangkit tenaga segalanya. Di server, generasi aktif konten berdasarkan algoritma atau data basis data adalah dorongan besar dan terus berkembang sejauh mungkin ada beberapa file pada disk - tentu saja, kami menyimpan file gambar atau skrip sebagai file di server web dan memiliki peramban MENDAPATKANnya, tetapi semakin banyak gambar yang ditampilkan peramban dan skrip yang dijalankan bukan file yang dapat Anda buka di penjelajah file Anda, mereka menghasilkan konten yang merupakan output dari beberapa proses kompilasi yang dilakukan sesuai permintaan , SVG yang menjelaskan cara menggambar piksel daripada array bitmap piksel, atau JavaScript yang dipancarkan dari bentuk skrip tingkat tinggi seperti TypeScript

Dalam membuat halaman multi megabyte modern mungkin hanya sebagian kecil dari itu sekarang konten tetap pada disk; data basis data diformat dan dibentuk menjadi html yang akan dikonsumsi oleh browser dan dilakukan oleh server sebagai respons terhadap beberapa rutin pemrograman yang berbeda yang dirujuk dalam beberapa cara oleh url

Saya menyebutkan dalam komentar untuk pertanyaan bahwa itu agak seperti lingkaran penuh. Kembali ketika komputer berharga ratusan ribu dan ruang yang penuh, itu biasa untuk memungkinkan banyak pengguna menggunakan satu mainframe pusat yang sangat kuat melalui ratusan terminal bodoh - papan kunci dan mouse, layar hijau, kirim beberapa teks, dapatkan beberapa teks keluar. Seiring waktu dengan meningkatnya daya komputasi dan harga turun, orang mulai berakhir dengan komputer meja lebih kuat dari mainframe awal dan kemampuan untuk menjalankan aplikasi yang kuat secara lokal sehingga model mainframe menjadi usang. Itu tidak pernah hilang, karena hal-hal baru saja berevolusi untuk bergeser ke arah lain dan agak kembali ke server pusat yang menyediakan sebagian besar fungsi aplikasi yang berguna dan seratus komputer klien yang melakukan sangat sedikit kecuali menggambar di layar, dan mengirim dan menerima data ke / dari server. Masa sementara di mana komputer Anda cukup pintar untuk menjalankan salinan kata dan pandangannya sendiri pada saat yang sama telah memberikan jalan kembali ke kantor online, di mana browser Anda adalah perangkat untuk menggambar gambar di layar dan mengedit dokumen / email yang Anda inginkan. sedang menulis sebagai sesuatu yang hidup di server, disimpan di sana, dikirim dan dibagikan dengan pengguna lain semua sebagai anggapan bahwa browser hanyalah sebuah shell yang memberikan tampilan sebagian pada satu waktu hal ini yang hidup di tempat lain

Dari jawaban, saya mengerti mengapa konsep metode ada .. Ini mengarah ke pertanyaan terkait lainnya:

Misalnya dalam tautan penulisan gmail, permintaan dan data PUT / POST akan dikirim. Bagaimana browser mengetahui metode mana yang digunakan?

Ini menggunakan GET secara default, dengan konvensi / spec karena itulah yang diputuskan akan terjadi ketika Anda mengetikkan url dan tekan kembali

Apakah halaman gmail yang dikirim oleh server menyertakan nama metode yang digunakan ketika memanggil gmail membuat permintaan?

Ini adalah salah satu hal penting yang saya singgung dalam komentar di atas. Di web modern ini bahkan bukan tentang halaman lagi. Setelah halaman adalah file di disk, browser akan DAPATKAN. Kemudian mereka menjadi halaman yang sebagian besar dihasilkan secara dinamis dengan memasukkan data ke dalam templat. Tapi itu masih melibatkan proses "permintaan halaman baru dari server, dapatkan halaman, tunjukkan halaman". Tukar halaman menjadi sangat licin; Anda tidak melihat mereka memuat dan mengubah ukuran dan menyentak tata letak mereka sehingga terlihat lebih halus tapi itu masih browser yang mengganti satu seluruh halaman atau bagian dari halaman dengan yang lain

Cara modern dalam melakukan sesuatu adalah dengan aplikasi satu halaman; browser memiliki dokumen dalam memori yang ditampilkan dengan cara tertentu, scripting panggilan ke server dan mendapatkan beberapa nugget info kembali, dan memanipulasi dokumen sehingga bagian halaman berubah secara visual untuk menampilkan info baru - semuanya berjalan tanpa browser pernah memuat halaman baru lainnya; itu hanya menjadi UI di mana sebagian pembaruan seperti aplikasi klien seperti kata atau pandangan. Elemen-elemen baru muncul di atas elemen-elemen lain dan dapat diseret di sekitar simulasi jendela dialog dll. Semua ini adalah mesin skrip browser mengirim permintaan menggunakan metode http apa pun yang diinginkan pengembang, mendapatkan data kembali dan menyodok pada dokumen yang dibuat oleh browser. Anda dapat membayangkan bahwa peramban modern adalah perangkat yang brilian yang mirip dengan keseluruhan sistem operasi atau komputer virtual; perangkat yang dapat diprogram yang memiliki cara yang cukup standar untuk menggambar sesuatu di layar, memutar suara, menangkap input pengguna dan mengirimkannya untuk diproses. Yang harus Anda lakukan untuk membuatnya menggambar UI Anda adalah menyediakannya dengan beberapa html / css yang membuat UI kemudian tweak html terus-menerus untuk membuat browser mengubah apa yang menggambar. Heck, orang-orang begitu terbiasa melihat bilah alamat berubah / menggunakannya sebagai arah niat sehingga aplikasi halaman tunggal akan mengubah url secara terprogram meskipun tidak ada navigasi (meminta seluruh halaman baru) sedang dilakukan Yang harus Anda lakukan untuk membuatnya menggambar UI Anda adalah menyediakannya dengan beberapa html / css yang membuat UI kemudian tweak html terus-menerus untuk membuat browser mengubah apa yang menggambar. Heck, orang-orang begitu terbiasa melihat bilah alamat berubah / menggunakannya sebagai arah niat sehingga aplikasi halaman tunggal akan mengubah url secara terprogram meskipun tidak ada navigasi (meminta seluruh halaman baru) sedang dilakukan Yang harus Anda lakukan untuk membuatnya menggambar UI Anda adalah menyediakannya dengan beberapa html / css yang membuat UI kemudian tweak html terus-menerus untuk membuat browser mengubah apa yang menggambar. Heck, orang-orang begitu terbiasa melihat bilah alamat berubah / menggunakannya sebagai arah niat sehingga aplikasi halaman tunggal akan mengubah url secara terprogram meskipun tidak ada navigasi (meminta seluruh halaman baru) sedang dilakukan

ketika kita memanggil www.gmail.com, itu harus menggunakan metode GET, bagaimana browser tahu bahwa metode ini digunakan?

Benar. Karena itu ditentukan. Permintaan pertama adalah karena secara historis selalu ada- DAPATKAN html awal untuk menggambar UI, lalu tusuk dan manipulasi selamanya, atau dapatkan halaman lain dengan skrip lain yang menyodok dan memanipulasi dan membuat UI reaktif yang responsif

Seperti yang beberapa jawaban katakan, kita dapat membuat pengguna baru pada metode DELETE, maka hal ini menimbulkan pertanyaan tentang maksud metode di dalam protokol http, karena pada akhirnya, itu benar-benar tergantung pada server fungsi apa yang mereka inginkan untuk memetakan URL ke . Mengapa klien harus memberi tahu server metode apa yang digunakan untuk URL.

Sejarah. Warisan. Kami secara teoritis dapat membuang semua metode http besok - kami berada pada tingkat kecanggihan pemrograman di mana metode usang karena URL dapat diproses sejauh mereka dapat menjadi mekanisme switching yang menunjukkan ke server bahwa Anda ingin menyimpan data di badan sebagai konsep email, atau menghapus konsep - tidak ada file / email / draft / save / 1234 di server - server diprogram untuk memilih url terpisah dan tahu apa yang harus dilakukan dengan data tubuh- simpan sebagai konsep email di bawah id 1234

Jadi tentu saja mungkin untuk menghilangkan metode, kecuali untuk beratnya kompatibilitas warisan yang tumbuh di sekitar mereka. Lebih baik menggunakannya hanya untuk apa yang Anda butuhkan tetapi sebagian besar mengabaikannya dan alih-alih menggunakan apa pun yang Anda butuhkan agar pekerjaan Anda berhasil. Kami masih memerlukan metode yang sudah ditentukan karena Anda harus ingat bahwa itu berarti sesuatu bagi browser dan server yang kami gunakan untuk membuat aplikasi. Skrip sisi klien ingin menggunakan browser yang mendasarinya untuk mengirim data, perlu menggunakan metode yang akan membuat browser melakukan apa yang diminta - mungkin POST karena MENDAPATKAN semua info variabel ke dalam url dan yang memiliki batas panjang di banyak server. Klien menginginkan respons panjang dari server - jangan gunakan HEAD karena mereka tidak seharusnya memiliki badan respons sama sekali.

HTTP dapat dianggap sebagai satu kasus spesifik dari prinsip-prinsip umum Panggilan Prosedur Jarak Jauh: Anda memberi tahu server apa yang Anda inginkan dengan beberapa bidang variabel dalam permintaan, server merespons sesuai. Pada saat ini, karena interaktivitas yang kompleks dari 'Web 2.0,' fitur-fitur yang sama ini didorong di setiap bidang berdasarkan permintaan: URL, tajuk, badan — dan setiap appserver dan aplikasi memahami mereka dengan caranya sendiri. Namun, awalnya web lebih sederhana, menggunakan halaman statis, dan diperkirakan bahwa metode HTTP memberikan tingkat interaktivitas yang cukup. Khususnya, HTTP memiliki banyak metode yang jarang digunakan, jika pernah, dengan beberapa dari mereka hanya melihat cahaya berkat REST. Misalnya PUT dan DELETE sudah hampir mati sebelum REST, dan TRACE dan PATCH masih afaik. Kesimpulannya adalah bahwa model HTTP dari RPC tidak

REST melakukan kebalikan dari apa yang Anda usulkan, dengan mencatat bahwa metode HTTP melayani kasus penggunaan CRUD khas sebagian besar aplikasi jika PUT dan DELETE dikembalikan.

Perhatikan juga bahwa metode HTTP memiliki semantik yang ditugaskan untuk mereka, yang dihormati oleh browser dan middleware seperti server proxy: permintaan POST, PUT, DELETE, dan PATCH mungkin memiliki efek samping dan kemungkinan tidak akan idempoten, jadi aplikasi sisi klien dan middleware berhati-hati untuk tidak memecat permintaan ini tanpa tindakan tegas dari pengguna. Dalam praktiknya, aplikasi web yang dirancang dengan buruk memang menggunakan GET untuk tindakan yang tidak aman, dan misalnya prefetcher Google Web Accelerator menyebabkan masalah dengan menghapus banyak data di situs tersebut , sehingga beta-nya ditangguhkan segera setelah diluncurkan.

Jadi, untuk menjawab pertanyaan 'bisakah kita': tentu saja, Anda hanya perlu menyepakati protokol yang akan memberi tahu aplikasi server tindakan apa yang ingin Anda lakukan, dan kemudian Anda menempatkan argumen di suatu tempat di URL / tubuh — seperti item target untuk tindakan. Serangkaian tindakan hanya dibatasi oleh aplikasi tertentu, sehingga Anda memerlukan protokol yang dapat diperluas. Tetapi Anda harus memberi tahu aplikasi klien tahu permintaan mana yang aman, dan mungkin mempertimbangkan nuansa lain, seperti kontrol cache.

Dari sudut pandang pribadi saya sebagai pengembang, ini dapat membuat membuat titik akhir API lebih mudah. Misalnya jika saya menulis pengontrol yang mengelola produk di situs web, saya dapat menggunakan URL yang sama untuk melakukan beberapa operasi berbeda.

Contoh:

GET https://example.com/api/products/1234

Ini akan mengambil detail produk 1234.

POST https://example.com/api/products/1234

Ini akan membuat produk dengan ID 1234 menggunakan data di badan permintaan.

PUT https://example.com/api/products/1234

Ini akan memperbarui produk 1234 dengan data di badan permintaan.

DELETE https://example.com/api/products/1234

Ini akan menghapus produk dengan ID 1234.

Saya bisa membuat titik akhir yang berbeda untuk setiap operasi tetapi itu akan mempersulit proses dan membuatnya kurang dimengerti untuk pengembang lain.

Apa perlunya metode seperti GET dan POST dalam protokol HTTP?

Tampaknya Anda lupa masa lalu ketika server HTTP ada di sana hanya untuk melayani file ; tidak menjalankan skrip, CGI, atau membuat konten dinamis semacam itu.

Metode permintaan adalah kumpulan kata kerja standar standar tentang apa yang harus dilakukan dengan file-file itu ...

• DAPATKAN berarti mengunduh
• KEPALA berarti mendapat informasi
• PUT berarti mengunggah
• HAPUS berarti menghapus
• POST berarti mengirim data ke
• OPSI berarti memberi tahu saya apa yang bisa saya lakukan

Pada hari HTTP / 0.9, baris permintaan adalah satu - satunya hal di leg permintaan protokol; tidak ada header permintaan, tidak ada header respons. Anda cukup mengetik GET /somefile, tekan Enter, server akan mengembalikan tubuh respons (yaitu konten HTML), dan oke terima kasih (yaitu, tutup koneksi).

Jika Anda hanya ingin bertanya mengapa itu dirancang seperti ini ? Jawaban saya adalah karena pada awalnya ditulis untuk menangani jenis pertukaran konten yang ada saat itu , yaitu penyajian file HTML statis atas permintaan pengguna.

Namun, jika Anda bermaksud bertanya tentang cara memperlakukan semantik ini di server aplikasi modern ...

Bisakah kita tidak mengimplementasikan protokol HTTP hanya dengan menggunakan tubuh permintaan dan badan tanggapan?

Apakah menerapkan berbagai metode HTTP benar-benar diperlukan?

Jawaban saya adalah: lakukan apa pun yang ingin Anda lakukan, tetapi perlu diingat bahwa Anda tidak boleh menerapkan logika aplikasi dengan cara yang bertentangan dengan harapan protokol : harapan seperti GET tidak boleh mengubah data (atau sangat longgar, memiliki setidaknya hasil idempoten ), KEPALA harus memiliki hasil yang sama dengan GET tetapi tanpa badan respon, PUT harus membuat konten target URI tersedia (jika berhasil).

Jika Anda menentang harapan tanpa mempertimbangkan implikasinya , berbagai hal tidak menyenangkan akan terjadi, seperti ...

• Saat Anda memilih metode GET untuk penggunaan pengiriman data, server mungkin meludahkan 414 kesalahan " URI Terlalu Panjang " di wajah Anda.
• Ketika Anda memilih metode GET menjadi modifikasi penggunaan data, Anda akan menemukan bahwa modifikasi kadang-kadang tidak melewati ketika pengguna berada di belakang proxy caching, atau modifikasi yang tidak terduga akan terjadi ketika pengguna mengingat URL dari bookmark (atau ketika crawler web mencapainya) .
• Ketika Anda merespons metode HEAD secara tidak benar, Anda akan menemukan bahwa alat pemeriksaan situs otomatis Anda (mis. wget --spiderJaminan) di situs Anda.
• Ketika Anda memilih metode POST ke dalam unduhan konten, Anda akan menemukan bahwa bookmark atau bahkan memasukkan URL ke browser tidak akan berfungsi.
• Dan masih banyak lagi...

" Pemula tahu aturan, tapi veteran tahu pengecualian. "

Bagaimanapun, Anda mungkin akhirnya menemukan beberapa alasan yang sah untuk melanggar beberapa aturan untuk beberapa kasus penggunaan yang sempit; tetapi pastikan untuk melakukan riset dan mempertimbangkan semua kemungkinan. Jika tidak, Anda pada akhirnya akan menghentikan interoperabilitas, dan merusak "pengalaman pengguna".

Tidak ada jaminan bahwa pengguna selalu menggunakan peluncuran mengkilap terbaru dari klien merek-utama / agen-pengguna yang Anda uji. Mereka dapat menggunakan merek lokal yang disesuaikan dengan kebutuhan mereka (termasuk saya), yang mereka pesan dari toko khusus di sebelah, atau yang vintage yang mereka gali dari gudang. Bahkan dengan semua ini, situs Anda masih diharapkan untuk memberikan layanan yang masuk akal. Itulah alasan mengapa kita memiliki standar.

Melanggar standar secara sembarangan juga berarti Anda menerapkan diskriminasi pada pengguna Anda.

Memang benar secara teori kita bisa menggunakan semua tempat dan itu akan semacam pekerjaan. Beberapa perangkat lunak bahkan menggunakan GET dengan badan permintaan (Saya sedang melihat Anda elasticsearch / kibana). Ini tentu saja merupakan hal yang mengerikan.

Alasan yang paling penting adalah karena metode yang berbeda memiliki semantik yang berbeda. Beberapa aman, beberapa idempoten. Beberapa dari keduanya. Lihat yang mana

Ini penting misalnya ketika berinteraksi dengan aplikasi lain. GET titik akhir tidak seharusnya memiliki efek samping. Ini penting ketika google merayapi sisi Anda. PUT seharusnya idempoten yang berarti klien bebas untuk mencoba lagi jika terjadi kegagalan. Ini bukan kasus untuk POST yang mengapa browser harus memiliki kotak konfirmasi jelek jika Anda menekan f5 pada permintaan posting.

Lihat apa yang bisa terjadi jika Anda menggunakan GET di mana Anda seharusnya menggunakan POST

Anda juga dapat menganggap GET, POST, dll sebagai kelebihan fungsi yang sama, atau bahkan sebagai getter dan setter.

GET_MyVar() tidak akan mengambil param input (alias Badan Permintaan), tetapi mengembalikan sesuatu.

POST_MyVar(string blah)melakukan sesuatu dengan input (sekali lagi, badan permintaan) dan dapat mengembalikan sesuatu. (Itu juga perlu setidaknya mengembalikan kode respons, sehingga kita tahu fungsi berlari !!)

DELETE_MyVar() Mungkin juga tidak mengambil apa-apa dan diharapkan menghapus sesuatu.

Ya, kita bisa menerapkan semuanya dengan:
MyVar(string Action, string? blah)

Dengan cara ini kami dapat menerima hanya satu panggilan dan kemudian memilih apa yang harus dilakukan berdasarkan beberapa parameter lain.

Tetapi salah satu kemudahan dari pendekatan ini adalah memungkinkan peramban dan server untuk mengoptimalkan cara kerjanya. Misalnya, mungkin server ingin memblokir semua permintaan di mana Action==DELETE. Mungkin browser ingin menyimpan hal-hal di mana Action==GET.Jika tidak, dalam setiap fungsi kita harus menulisif (Action==Delete) {return AngryFace}

Tidak ada persyaratan untuk mengimplementasikan semuanya persis sesuai protokol, tetapi protokol pada dasarnya adalah seperangkat aturan yang kita semua putuskan untuk diikuti. Dengan begitu, saya bisa menebak dengan mudah apa yang akan dilakukan situs Anda, bahkan jika saya belum melihat servernya!

Metode HTTP melayani berbagai tujuan. Secara umum, GETuntuk unduhan dan POSTuntuk unggahan.

Satu-satunya cara mengimplementasikan bagian dari protokol HTTP hanya dengan menggunakan badan permintaan dan badan tanggapan adalah dengan mengimplementasikan POST. GETtidak memiliki badan permintaan. Itu hanya memiliki permintaan itu sendiri dengan header, tetapi tidak ada tubuh. Itu hanya permintaan dokumen untuk diunduh. POSTmemiliki badan permintaan (unggah file) dan badan tanggapan (dokumen yang menunjukkan hasilnya).

Jadi bisa Anda hanya menerapkan POSTdan dilakukan? Tidak jika Anda ingin situs Anda dapat digunakan di browser standar. Jenis permintaan default yang dikirim oleh browser adalah GET. POSTpermintaan biasanya hanya dikirim ketika formulir di halaman web dikirimkan atau untuk panggilan AJAX. Hanya jika server khusus ini hanya digunakan untuk panggilan AJAX, dan tidak untuk halaman yang terlihat oleh pengguna, barulah Anda bisa lolos begitu POSTsaja.

Peramban juga terkadang mengirim HEADpermintaan untuk memeriksa apakah suatu dokumen telah berubah sejak terakhir kali mereka mengunduhnya, sehingga disarankan untuk setidaknya mengimplementasikannya juga.

Bagaimanapun, tidak ada alasan yang baik untuk mengimplementasikan server web untuk situs Anda dari awal. Protokol HTTP rumit. Selain berbagai metode, Anda juga harus menerapkan permintaan pipelining dan chunked. Jauh lebih mudah untuk membangun aplikasi web Anda di atas server web seperti Apache, Nginx, atau IIS yang menangani protokol HTTP untuk Anda. Anda menyebutkan Servlets, jadi mungkin Anda harus menggunakan server web Tomcat atau JBoss yang menjalankan Servlets.

Anda benar, kita bisa melakukan itu, GET, POST, PUT dll hanya konvensi historis jika saya punya cara HTTP akan digantikan hanya dengan metode POST dan tidak ada yang lain, meskipun saya harus mengakui menghilangkan GET akan menjadi usaha besar, itu tidak bisa dilakukan, kuda itu sudah melesat yang satu itu

Protokol yang Anda usulkan akan jauh lebih tidak aman terhadap peretas.

Ada alasan mengapa situs web telah pindah dari menyimpan informasi tentang variabel dan semacamnya di URL, dan alasan itu sederhana: memberikan penyerang cara yang sangat sederhana untuk menyerang sistem Anda. Dengan mengamati informasi URL plaintext, mereka dapat menentukan cara pembuatan data yang dikirim ke server web Anda; mereka kemudian dapat menggunakan informasi ini untuk melakukan serangan pada server Anda dengan menggunakan URL yang dibuat khusus yang memungkinkan mereka untuk menyuntikkan kode atau data berbahaya ke server Anda.