Qual è la necessità di metodi come GET e POST nel protocollo HTTP?

Non possiamo implementare il protocollo HTTP usando solo un corpo di richiesta e un corpo di risposta?

Ad esempio, l'URL conterrà la richiesta, che verrà mappata su una funzione in base al linguaggio di programmazione sul lato server, ad esempio un Servlet e in risposta, la risposta HTML e JavaScript verrà inviata attraverso.

Perché il protocollo HTTP ha nozione di metodi?

Dalle risposte, ho un'idea del perché esiste il concetto di metodi ... Questo porta a un'altra domanda correlata:

Ad esempio, nel link di composizione di Gmail, verranno inviati la richiesta PUT / POST e i dati. In che modo il browser viene a sapere quale metodo utilizzare? La pagina gmail inviata dal server include il nome del metodo da utilizzare quando si chiama la richiesta di composizione di gmail? quando chiamiamo www.gmail.com, deve utilizzare il metodo GET, come fa il browser a sapere che questo metodo deve essere utilizzato?

PS : Non ho abbastanza crediti per commentare le risposte, quindi non sono in grado di commentare molte domande sollevate da persone legate alle intenzioni dietro questa domanda.

Come dicono alcune risposte, possiamo creare nuovi utenti sul metodo DELETE, quindi questo solleva la domanda dietro l'idea dei metodi nel protocollo http, perché alla fine, dipende totalmente dai server su quale funzione vogliono mappare un URL . Perché il client dovrebbe dire ai server quali metodi usare per un URL.

Si noti che la domanda è stata modificata / chiarita da quando questa risposta è stata scritta per la prima volta. Un'ulteriore risposta all'ultima iterazione della domanda è dopo la seconda regola orizzontale

Qual è la necessità di metodi come GET e POST nel protocollo HTTP?

Insieme ad alcune altre cose come i formati di intestazione, le regole per la separazione di intestazioni e corpi, formano la base del protocollo HTTP

Non possiamo implementare il protocollo HTTP usando solo un corpo di richiesta e un corpo di risposta?

No, perché qualsiasi cosa tu abbia creato non sarebbe il protocollo HTTP

Ad esempio, l'URL conterrà la richiesta, che verrà mappata su una funzione in base al linguaggio di programmazione sul lato server, ad esempio un Servlet e in risposta, la risposta HTML e JavaScript verrà inviata attraverso.

Congratulazioni, hai appena inventato un nuovo protocollo! Ora, se si desidera creare un organismo standard per guidarlo e mantenerlo, svilupparlo, ecc., Potrebbe un giorno superare l'HTTP

Apprezzo che questo sia un po 'ironico, ma non c'è nulla di magico in Internet, TCP / IP o nelle comunicazioni tra server e client. Si apre una connessione e si inviano alcune parole lungo il filo, formando una conversazione. La conversazione deve davvero aderire ad alcune specifiche ratificate ad entrambe le estremità se le richieste devono essere comprese e le risposte sensate consegnate. Questo non è diverso da qualsiasi dialogo nel mondo. Parli inglese, il tuo vicino parla cinese. Spero che agitare la mano, indicare e scuotere il pugno sia sufficiente a trasmettere il tuo messaggio che non vuoi che parcheggi la sua auto davanti a casa tua.

Di nuovo su Internet, se si apre un socket su un server Web conforme a HTTP e si invia quanto segue:

EHLO
AUTH LOGIN

(L'inizio di una trasmissione e-mail SMTP) non otterrai una risposta ragionevole. Potresti creare il client conforme SMTP più perfetto, ma il tuo server web non ci parlerà perché questa conversazione riguarda tutto il protocollo condiviso - nessun protocollo condiviso, nessuna gioia.

Questo è il motivo per cui non è possibile implementare il protocollo HTTP senza implementare il protocollo HTTP; se ciò che scrivi non è conforme al protocollo, semplicemente non è il protocollo - è qualcos'altro e non funzionerà come specificato nel protocollo

Se corriamo con il tuo esempio per un momento; dove il client si connette e indica semplicemente qualcosa che assomiglia a un URL .. E il server lo capisce e invia semplicemente qualcosa che assomiglia a HTML / JS (una pagina Web), quindi potrebbe funzionare. Cosa hai salvato però? Un paio di byte per non dire GET? Qualche altro in più per abbandonare quelle fastidiose intestazioni ... Anche il server ne ha salvate alcune, ma cosa succede se non riesci a capire cosa ti ha inviato? E se chiedessi un URL che termina in JPEG e ti ha inviato alcuni byte che creano un'immagine, ma è in formato PNG? Un PNG incompleto. Se solo avessimo un'intestazione che dicesse quanti byte stava andandoper inviare, quindi sapremmo se il numero di byte che abbiamo ricevuto era effettivamente l'intero file o no. Che cosa succede se il server gzipizza la risposta per risparmiare un po 'di larghezza di banda ma non te lo dice? Trascorrerai una notevole potenza di calcolo cercando di capire cosa ti ha inviato.

Alla fine della giornata, abbiamo bisogno di metainformation - informazioni sulle informazioni; abbiamo bisogno di intestazioni; abbiamo bisogno di file per avere nomi, estensioni, date di creazione. Abbiamo bisogno che le persone abbiano compleanni, per favore, grazie, ecc. - il mondo è pieno di protocolli e informazioni sul contesto, quindi non dobbiamo sederci e lavorare tutto da zero tutto il tempo. Costa un po 'di spazio di archiviazione, ma ne vale la pena

L'implementazione di vari metodi HTTP è davvero necessaria?

Probabilmente, non è necessario implementare l'intero protocollo specificato, e questo di solito è vero per qualsiasi cosa. Non conosco ogni parola in inglese; il mio vicino cinese è anche uno sviluppatore di software ma in un settore diverso e non conosce nemmeno il cinese per alcuni dei termini usati nel mio settore e tanto meno l'inglese. La cosa buona è, però, che entrambi possiamo prendere un documento sull'implementazione di HTTP, lui può scrivere il server e io posso scrivere il client, in diversi linguaggi di programmazione su architetture diverse, e funzionano ancora perché aderiscono al protocollo

Può darsi che nessuno dei tuoi utenti emetterà mai qualcosa di diverso da una richiesta GET, non userà connessioni persistenti, invierà qualcosa di diverso da JSON come corpo o dovrà accettare qualsiasi cosa diversa da text / plain in modo da poter scrivere un web server veramente ridotto che soddisfi solo le esigenze molto limitate del browser client. Ma non potevi semplicemente decidere arbitrariamente di eliminare le regole di base che rendono "un po 'di testo che passa giù un socket" che cos'è HTTP; non puoi abbandonare l'idea di base che la richiesta sarà una stringa come:

VERB URL VERSION
header: value

maybe_body

E la risposta avrà una versione, un codice di stato e forse delle intestazioni. Se cambi qualcosa di tutto ciò - non è più HTTP - è qualcos'altro e funzionerà solo con qualcosa progettato per capirlo. HTTP è quello che è con queste definizioni, quindi se si desidera implementarlo, è necessario seguire le definizioni

Aggiornare

La tua domanda si è leggermente evoluta, ecco qualche risposta a ciò che chiedi:

Perché il protocollo HTTP ha nozione di metodi?

Storicamente è necessario apprezzare che le cose erano molto più rigide nella loro progettazione e implementazione, anche nella misura in cui gli script non esistevano e persino l'idea che le pagine potessero essere dinamiche, generate al volo in memoria e spinte verso il basso invece di essere un file statico su disco richiesto dal client, letto e inserito nel socket, non esisteva. Poiché il Web molto precoce era incentrato sulla nozione di pagine statiche che contenevano collegamenti ad altre pagine, tutte le pagine esistevano sul disco e la navigazione sarebbe stata dal terminale principalmente effettuando richieste GET per le pagine agli URL, il server sarebbe in grado di mappare l'URL a un file su disco e inviarlo. C'era anche l'idea che la rete di documenti che si collegavano tra di loro e altrove dovrebbe essere una evoluzione,

Ciò fornisce un contesto storico per i metodi: una volta l'URL era il bit inflessibile e si riferiva semplicisticamente alle pagine sul disco, quindi il metodo era utile perché permetteva al client di descrivere quale intenzione aveva per il file e il server avrebbe elaborare il metodo in modo diverso. Non c'era davvero l'idea che gli URL fossero virtuali o usati per cambiare o mappare nella visione originale di un ipertesto (ed era davvero solo testo) web

Non intendo che questa risposta sia una documentazione del record storico con date e riferimenti citati esattamente quando le cose hanno iniziato a cambiare - per questo probabilmente puoi leggere Wikipedia - ma è sufficiente dire che nel tempo il desiderio di il Web sarà più raccolto e ad ogni estremità della connessione server-client le opportunità per creare una ricca esperienza multimediale che stiamo espandendo. I browser supportano un'enorme proliferazione di tag per la formattazione dei contenuti, ognuno dei quali corre per implementare le funzionalità di ricchezza multimediale indispensabili e nuovi modi per rendere le cose eleganti.

Lo scripting è arrivato sul lato client e i plug-in e le estensioni del browser, tutti volti a trasformare il browser in un potente motore di tutto. Alla fine del server, la generazione attiva di contenuti basati su algoritmi o dati di database è stata la grande spinta e continua a svilupparsi nella misura in cui probabilmente ci sono più pochi file sul disco - certo, manteniamo un'immagine o un file di script come file su il web server e il browser lo ottengono, ma sempre più le immagini che il browser mostra e gli script che esegue non sono file che è possibile aprire in Esplora file, sono contenuti generati che sono l'output di alcuni processi di compilazione eseguiti su richiesta , SVG che descrive come disegnare pixel anziché una matrice bitmap di pixel o JavaScript che è stato emesso da una forma di livello superiore di script come TypeScript

Nel rendere moderne pagine multi-megabyte, probabilmente solo una parte di esso è ora contenuto fisso su un disco; i dati del database sono formattati e modellati in html che il browser consumerà ed è fatto dal server in risposta a più diverse routine di programmazione a cui fa riferimento in qualche modo l'URL

Ho detto nei commenti alla domanda che è un po 'come il cerchio completo. Ai tempi in cui i computer costavano centinaia di migliaia e riempivano le stanze era comune consentire a più utenti di utilizzare l'unico super potente mainframe centrale tramite centinaia di terminali stupidi: una tastiera e un mouse, uno schermo verde, inviare del testo, ottenere alcuni sms. Con il passare del tempo, con l'aumento della potenza di calcolo e il calo dei prezzi, le persone hanno iniziato a finire con computer desktop più potenti dei primi mainframe e la possibilità di eseguire localmente potenti app in modo da rendere obsoleto il modello di mainframe. Non è mai andato via, perché le cose si sono evolute per spostarsi dall'altra parte e in qualche modo tornare a un server centrale che fornisce la maggior parte delle funzionalità delle app utili e un centinaio di computer client che fanno ben poco tranne che disegnare sullo schermo, e inviare e ricevere dati da / verso il server. Quel periodo intermedio in cui il tuo computer è stato abbastanza intelligente da eseguire la sua stessa copia di Word e Outlook allo stesso tempo ha di nuovo lasciato il posto a Office online, in cui il tuo browser è un dispositivo per disegnare immagini sullo schermo e modificare il documento / e-mail ' sto scrivendo come una cosa che vive sul server, viene salvata lì, inviata e condivisa con altri utenti tutto come l'idea che il browser sia solo una shell che fornisce una visione parziale in qualsiasi momento di questa cosa che vive altrove

Dalle risposte, ho un'idea del perché esiste il concetto di metodi ... Questo porta a un'altra domanda correlata:

Ad esempio, nel link di composizione di Gmail, verranno inviati la richiesta PUT / POST e i dati. In che modo il browser viene a sapere quale metodo utilizzare?

Utilizza GET per impostazione predefinita, per convenzione / specifica poiché è ciò che viene decretato quando si digita un URL e si preme Invio

La pagina gmail inviata dal server include il nome del metodo da utilizzare quando si chiama la richiesta di composizione di gmail?

Questa è una delle cose chiave a cui alludo nei commenti sopra. Nel web moderno non si tratta più nemmeno di pagine. Una volta che le pagine erano file su disco, il browser avrebbe ottenuto. Quindi sono diventate pagine che sono state principalmente generate dinamicamente inserendo i dati in un modello. Ma comportava ancora un processo "richiedi una nuova pagina dal server, ottieni una pagina, mostra la pagina". Lo scambio di pagine è diventato davvero fluido; non li hai visti caricare, ridimensionare e scuotere il loro layout in modo da renderlo più fluido ma era ancora il browser che sostituiva un'intera pagina o parte di una pagina con un'altra

Il modo moderno di fare le cose è con un'applicazione a pagina singola; il browser ha un documento in memoria che viene visualizzato in un certo modo, lo scripting chiama a thebservr e recupera un po 'di informazioni, e manipola il documento in modo che parte della pagina cambi visivamente per mostrare le nuove informazioni - tutto il resto funziona senza il browser carica sempre un'altra nuova pagina; è appena diventata un'interfaccia utente in cui parti di essa si aggiornano proprio come un'app client tipica come word o Outlook. Nuovi elementi vengono visualizzati sopra altri elementi e possono essere trascinati attorno alla simulazione di finestre di dialogo, ecc. Tutto questo È il motore di scripting del browser che invia richieste utilizzando il metodo http desiderato dallo sviluppatore, recuperando i dati e cercando il documento che il browser sta disegnando. Puoi immaginare che il browser moderno sia un dispositivo brillante che assomiglia a un intero sistema operativo o computer virtuale; un dispositivo programmabile che ha un modo abbastanza standardizzato di disegnare cose sullo schermo, riprodurre suoni, catturare l'input dell'utente e inviarlo per l'elaborazione. Tutto quello che devi fare per farlo disegnare la tua interfaccia utente è fornirgli un po 'di html / css che crea un'interfaccia utente, quindi modificare costantemente l'html per fare in modo che il browser cambi ciò che sta disegnando. Diamine, le persone sono così abituate a vedere la barra degli indirizzi cambiare / usarla come una direzione di intenti che una singola pagina app cambierà l'url a livello di codice anche se non viene eseguita alcuna navigazione (che richiede pagine completamente nuove) Tutto quello che devi fare per farlo disegnare la tua interfaccia utente è fornirgli un po 'di html / css che crea un'interfaccia utente, quindi modificare costantemente l'html per fare in modo che il browser cambi ciò che sta disegnando. Diamine, le persone sono così abituate a vedere la barra degli indirizzi cambiare / usarla come una direzione di intenti che una singola pagina app cambierà l'url a livello di codice anche se non viene eseguita alcuna navigazione (che richiede pagine completamente nuove) Tutto quello che devi fare per farlo disegnare la tua interfaccia utente è fornirgli un po 'di html / css che crea un'interfaccia utente, quindi modificare costantemente l'html per fare in modo che il browser cambi ciò che sta disegnando. Diamine, le persone sono così abituate a vedere la barra degli indirizzi cambiare / usarla come una direzione di intenti che una singola pagina app cambierà l'url a livello di codice anche se non viene eseguita alcuna navigazione (che richiede pagine completamente nuove)

quando chiamiamo www.gmail.com, deve utilizzare il metodo GET, come fa il browser a sapere che questo metodo deve essere utilizzato?

Vero. Perché è specificato. La prima richiesta è come è sempre stata- OTTENERE un codice HTML iniziale per disegnare un'interfaccia utente, quindi cercare o manipolarla per sempre o ottenere un'altra pagina con altri script che colpisca e manipoli e crei un'interfaccia utente reattiva reattiva

Come dicono alcune risposte, possiamo creare nuovi utenti sul metodo DELETE, quindi questo solleva la domanda dietro l'idea dei metodi nel protocollo http, perché alla fine, dipende totalmente dai server su quale funzione vogliono mappare un URL . Perché il client dovrebbe dire ai server quali metodi usare per un URL.

Storia. Legacy. Potremmo teoricamente lanciare tutti i metodi http domani - siamo a un livello di sofisticazione della programmazione in cui i metodi sono obsoleti perché gli URL sono processabili nella misura in cui possono essere il meccanismo di commutazione che indica al server in cui si desidera salvare i dati il corpo come bozza di e-mail o elimina una bozza - non esiste un file / e-mail / bozza / salvataggio / 1234 sul server - il server è programmato per separare quell'URL e sapere cosa fare con i dati del corpo - salva come bozza di posta elettronica con ID 1234

Quindi è certamente possibile eliminare i metodi, tranne l'enorme peso della compatibilità ereditaria che è cresciuta intorno a loro. È meglio usarli solo per ciò che è necessario, ma ignorarli in gran parte e invece utilizzare tutto ciò di cui hai bisogno per far funzionare le tue cose. Abbiamo ancora bisogno di metodi così specifici perché devi ricordare che significano qualcosa per il browser e il server su cui abbiamo creato le nostre app. Lo script lato client vuole usare il browser sottostante per inviare dati, deve usare un metodo che farà fare al browser come richiesto, probabilmente un POST perché GET racchiude tutte le sue informazioni variabili nell'URL e che ha un limite di lunghezza in molti server. Il client vuole una lunga risposta dal server - non usare un HEAD perché non dovrebbero assolutamente avere corpi di risposta.

L'HTTP può essere considerato come un caso specifico di principi generici di Remote Procedure Call: dici al server cosa vuoi con qualche campo variabile nella richiesta, il server risponde di conseguenza. Ormai, a causa della complessa interattività del "Web 2.0", queste stesse funzionalità sono inserite in ogni campo della richiesta: l'URL, le intestazioni, il corpo e ogni apperver e app li capisce a modo loro. Tuttavia, in origine il Web era più semplice, utilizzava pagine statiche e si pensava che i metodi HTTP fornissero il livello di interattività che sarebbe bastato. In particolare, HTTP ha molti metodi che vengono usati raramente, se non mai, con alcuni di essi vedono solo la luce grazie a REST. Ad esempio PUT e DELETE erano moribondi prima di REST, e TRACE e PATCH sono ancora invisibili. Il takeaway è che il modello HTTP di RPC non ha

REST ha fatto esattamente l'opposto di ciò che stai proponendo, osservando che i metodi HTTP servono i tipici casi d'uso CRUD della maggior parte delle app se PUT e DELETE vengono ripristinati.

Si noti inoltre che i metodi HTTP hanno una semantica assegnata a loro, che viene onorata da browser e middleware come i server proxy: le richieste POST, PUT, DELETE e PATCH possono avere effetti collaterali e probabilmente non essere idempotenti, quindi le app e il middleware sul lato client devono prestare attenzione non attivare queste richieste senza esplicita azione da parte dell'utente. In pratica, le app Web mal progettate utilizzavano GET per azioni non sicure e, ad esempio, il prefetcher di Google Web Accelerator causava problemi eliminando un sacco di dati su tali siti , quindi la sua beta veniva sospesa subito dopo il lancio.

Quindi, per rispondere alla domanda "possiamo": certo, devi solo concordare un protocollo che dirà all'app del server quale azione vuoi eseguire, e poi metti gli argomenti da qualche parte nell'URL / body, come il oggetto di destinazione per l'azione. L'insieme di azioni è limitato solo da app specifiche, quindi è necessario un protocollo estensibile. Ma dovrai far sapere alle app client quali richieste sono sicure e probabilmente prendere in considerazione altre sfumature, come il controllo della cache.

Dal mio punto di vista personale come sviluppatore, può rendere molto più semplice la creazione di endpoint API. Ad esempio, se scrivo un controller che gestisce i prodotti su un sito Web, posso utilizzare lo stesso URL per eseguire più operazioni diverse.

Esempi:

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

Ciò recupererà i dettagli del prodotto 1234.

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

Ciò creerà un prodotto con ID 1234 utilizzando i dati nel corpo della richiesta.

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

Ciò aggiornerà il prodotto 1234 con i dati nel corpo della richiesta.

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

Ciò eliminerà un prodotto con ID 1234.

Potrei realizzare endpoint diversi per ogni operazione, ma ciò complicherebbe il processo e lo renderebbe meno comprensibile per gli altri sviluppatori.

Qual è la necessità di metodi come GET e POST nel protocollo HTTP?

Sembra che hai dimenticato i vecchi tempi in cui i server HTTP erano lì solo per servire i file ; non eseguire script, CGI o creare contenuti dinamici di quel tipo.

I metodi di richiesta sono set di verbi standardizzati di base su cosa fare con quei file ...

• OTTENERE significa download
• HEAD significa ottenere informazioni su
• PUT significa upload
• ELIMINA significa rimuovere
• POST significa inviare i dati in
• OPZIONI significa dirmi cosa potrei fare

Nel giorno di HTTP / 0.9, la riga di richiesta è l' unica cosa nella parte richiesta del protocollo; nessuna intestazione richiesta, nessuna intestazione risposta. Basta digitare GET /somefile, premere Enter, il server restituirà il corpo della risposta (ad es. Contenuto HTML) e ok grazie ciao (cioè chiudi la connessione).

Se intendevi solo chiedere perché è stato progettato in questo modo ? La mia risposta è perché è stato originariamente scritto per gestire il tipo di scambio di contenuti esistente all'epoca , ovvero il servizio di file HTML statici su richiesta degli utenti.

Tuttavia, se intendevi chiedere come trattare queste semantiche nel moderno server delle applicazioni ...

Non possiamo implementare il protocollo HTTP usando solo un corpo di richiesta e un corpo di risposta?

L'implementazione di vari metodi HTTP è davvero necessaria?

La mia risposta è: fai tutto quello che vorresti fare, ma tieni presente che non dovresti implementare la logica dell'applicazione in un modo che sfida le aspettative del protocollo : aspettative come GET non dovrebbero cambiare i dati (o molto vagamente, avere almeno un risultato idempotente ), HEAD dovrebbe avere lo stesso risultato di GET ma senza il corpo di risposta, PUT dovrebbe rendere disponibile il contenuto dell'URI di destinazione (se riuscito).

Se vai contro le aspettative senza considerare attentamente le sue implicazioni , accadrebbero varie cose spiacevoli, come ...

• Quando si calpesta il metodo GET nell'uso dell'invio dei dati, il server potrebbe sputare in faccia 414 errore " URI Too Long ".
• Quando si calpesta il metodo GET nell'uso della modifica dei dati, si scopre che a volte la modifica non riesce quando l'utente si trova dietro un proxy di memorizzazione nella cache o si verificano modifiche impreviste quando l'utente richiama l'URL dal segnalibro (o quando i web crawler lo raggiungono) .
• Quando si risponde al metodo HEAD in modo improprio, si scoprirà che gli strumenti di controllo automatico del sito (ad es. wget --spider) Cauzione sul proprio sito.
• Quando si cala il metodo POST nel download di contenuti, si scopre che il bookmarking o persino l'inserimento dell'URL nel browser non funzionerà.
• E molti altri...

"Il principiante conosce le regole, ma i veterani conoscono le eccezioni. "

Ad ogni modo, potresti finire per trovare delle scuse valide per andare contro alcune delle regole per alcuni casi d'uso ristretti; ma assicurati di fare le tue ricerche e considera tutte le possibilità. Altrimenti, finirai per aumentare l'interoperabilità e rovinare le "esperienze degli utenti".

Non vi è alcuna garanzia che gli utenti utilizzino sempre la versione più recente dei client / agenti-agenti di marca tradizionali che hai testato. Possono usare un marchio locale che è su misura per le loro esigenze (me incluso), uno personalizzato che hanno ordinato dal negozio di specialità della porta accanto o uno vintage che hanno estratto da un ripostiglio. Anche con tutto ciò, i tuoi siti dovrebbero comunque offrire un servizio ragionevole. Questo è un motivo per cui abbiamo standard.

Rompere incurantemente lo standard significa anche applicare la discriminazione ai propri utenti.

È vero in teoria che potremmo usare per andare ovunque e sarebbe una specie di lavoro. Alcuni software usano persino GET con il corpo della richiesta (ti sto guardando elasticsearch / kibana). Questa ovviamente è una cosa orribile da fare.

Il motivo più importante è perché i diversi metodi hanno semantica diversa. Alcuni sono al sicuro, altri sono idempotenti. Alcuni sono entrambi. Vedi quali sono quali

Questo è importante, ad es. Quando si interagisce con altre applicazioni. Gli endpoint GET non dovrebbero avere effetti collaterali. Questo è importante quando Google esegue la scansione del tuo lato. PUT dovrebbe essere idempotente, il che significa che il client è libero di riprovare in caso di errore. Questo non è il caso di POST, motivo per cui i browser devono avere una brutta casella di conferma se si preme f5 su una richiesta di post.

Scopri cosa può succedere se usi GET dove avresti dovuto usare POST

Puoi anche pensare a GET, POST, ecc. Come sovraccarichi della stessa funzione, o addirittura come getter e setter.

GET_MyVar() non accetta un parametro di input (ovvero il corpo della richiesta), ma restituisce qualcosa.

POST_MyVar(string blah)fa qualcosa con l'input (di nuovo, il corpo della richiesta) e può restituire qualcosa. (Deve anche restituire almeno un codice di risposta, in modo che sappiamo che la funzione è stata eseguita !!)

DELETE_MyVar() Inoltre probabilmente non prende nulla e si prevede di eliminare qualcosa.

Sì, potremmo implementare tutto con:
MyVar(string Action, string? blah)

In questo modo potremmo accettare una sola chiamata e quindi scegliere cosa fare in base ad altri parametri.

Ma uno dei vantaggi di questo approccio è che consente a browser e server di ottimizzare il modo in cui queste cose funzionano. Ad esempio, forse il server vorrebbe bloccare tutte le richieste in cui Action==DELETE. Forse i browser vogliono memorizzare nella cache cose dove Action==GET.altrimenti, in ogni funzione dovremmo scrivereif (Action==Delete) {return AngryFace}

Non è necessario implementare tutto esattamente secondo il protocollo, ma il protocollo è fondamentalmente un insieme di regole che tutti abbiamo deciso di seguire. In questo modo, posso indovinare facilmente cosa farà il tuo sito, anche se non ho visto il server!

I metodi HTTP hanno scopi diversi. In generale, GETè per i download ed POSTè per i caricamenti.

L'unico modo per implementare parte del protocollo HTTP usando solo un corpo di richiesta e un corpo di risposta sarebbe quello di implementare POST. GETnon ha un corpo di richiesta. Ha solo la richiesta stessa con le intestazioni, ma nessun corpo. È solo una richiesta per il download di un documento. POSTha sia il corpo della richiesta (il caricamento del file) sia un corpo della risposta (il documento che mostra il risultato).

Quindi potresti semplicemente implementare POSTed essere fatto? Non se vuoi che il tuo sito sia utilizzabile nei browser standard. Il tipo di richiesta predefinito che i browser inviano è GET. POSTle richieste vengono in genere inviate solo quando vengono inviati moduli nelle pagine Web o per le chiamate AJAX. Solo se questo particolare server fosse utilizzato solo per le chiamate AJAX e non per le pagine visibili agli utenti, potresti essere in grado di cavartela POSTsolo.

I browser a volte inviano anche HEADrichieste per verificare se un documento è cambiato dall'ultima volta che lo hanno scaricato, quindi sarebbe consigliabile implementarlo almeno.

In ogni caso, non esiste un buon motivo per implementare un server Web per il tuo sito da zero. Il protocollo HTTP è complicato. Oltre ai vari metodi dovresti anche implementare richieste di pipeline e chunked. È molto più semplice costruire la tua applicazione web su un server web come Apache, Nginx o IIS che gestisce il protocollo HTTP per te. Menzionate Servlet, quindi forse dovreste usare i server Web Tomcat o JBoss che eseguono Servlet.

Hai ragione, potremmo fare proprio questo, GET, POST, PUT ecc. Sono solo convenzioni storiche se avessi il mio modo HTTP sarebbe stato sostituito con solo il metodo POST e nient'altro, anche se devo ammettere che eliminare GET sarebbe un'impresa enorme, non si poteva fare, il cavallo si è già scagliato contro quello

Il protocollo proposto sarebbe significativamente meno sicuro contro gli hacker.

C'è un motivo per cui i siti Web si sono allontanati dalla memorizzazione di informazioni su variabili e simili nell'URL e tale motivo è semplice: offre agli aggressori un modo molto semplice per attaccare il tuo sistema. Osservando le informazioni sull'URL in chiaro, possono determinare la modalità di costruzione dei dati inviati al tuo server web; possono quindi utilizzare queste informazioni per eseguire un attacco al tuo server utilizzando un URL appositamente costruito che consente loro di iniettare codice o dati dannosi sul tuo server.