¿Cuál es la necesidad de métodos como GET y POST en el protocolo HTTP?

¿No podemos implementar el protocolo HTTP usando solo un cuerpo de solicitud y un cuerpo de respuesta?

Por ejemplo, la URL contendrá la solicitud, que se asignará a una función dependiendo del lenguaje de programación del lado del servidor, por ejemplo, un Servlet y, en respuesta, se enviará una respuesta HTML y JavaScript.

¿Por qué el protocolo HTTP tiene noción de métodos?

De las respuestas, tengo una idea de por qué existe el concepto de métodos ... Esto lleva a otra pregunta relacionada:

Por ejemplo, en el enlace de redacción de gmail, se enviarán la solicitud PUT / POST y los datos. ¿Cómo llega el navegador a saber qué método usar? ¿La página de gmail enviada por el servidor incluye el nombre del método a utilizar cuando se llama a la solicitud de redacción de gmail? cuando llamamos a www.gmail.com, debe estar usando el método GET, ¿cómo sabe el navegador que debe usar este método?

PD : No tengo suficientes créditos para comentar las respuestas, por lo que no puedo comentar muchas preguntas planteadas por personas relacionadas con la intención detrás de esta pregunta.

Como dicen algunas respuestas, podemos crear nuevos usuarios en el método DELETE, y esto plantea dudas sobre la intención detrás de la noción de métodos en el protocolo http, porque al final del día, depende totalmente de los servidores a qué función quieren asignar una URL. . ¿Por qué el cliente debe decirle a los servidores qué métodos usar para una URL?

Tenga en cuenta que la pregunta ha cambiado / se ha aclarado desde que esta respuesta se escribió por primera vez. Otra respuesta a la última iteración de la pregunta es después de la segunda regla horizontal

¿Cuál es la necesidad de métodos como GET y POST en el protocolo HTTP?

Ellos, junto con algunas otras cosas como los formatos de encabezado, las reglas sobre cómo se separan los encabezados y los cuerpos, forman la base del protocolo HTTP

¿No podemos implementar el protocolo HTTP usando solo un cuerpo de solicitud y un cuerpo de respuesta?

No, porque lo que sea que hayas creado no sería el protocolo HTTP

Por ejemplo, la URL contendrá la solicitud, que se asignará a una función dependiendo del lenguaje de programación del lado del servidor, por ejemplo, un Servlet y, en respuesta, se enviará una respuesta HTML y JavaScript.

¡Felicitaciones, acabas de inventar un nuevo protocolo! Ahora, si desea configurar un cuerpo de estándares para conducirlo y mantenerlo, desarrollarlo, etc., podría superar a HTTP algún día

Aprecio que esto sea un poco irónico, pero no hay nada mágico en Internet, TCP / IP o la comunicación que se lleva a cabo entre servidores y clientes. Abre una conexión y envía algunas palabras por el cable, formando una conversación. La conversación realmente necesita adherirse a alguna especificación ratificada en ambos extremos para que las solicitudes se entiendan y se entreguen respuestas sensatas. Esto no es diferente a ningún diálogo en el mundo. Hablas inglés, tu vecino habla chino. Esperemos que su mano agitando, señalando y sacudiendo el puño sea suficiente para transmitir su mensaje de que no quiere que estacione su auto frente a su casa.

De nuevo en Internet, si abre un socket a un servidor web que cumple con HTTP y envía lo siguiente:

EHLO
AUTH LOGIN

(El inicio de una transmisión de correo electrónico SMTP), entonces no obtendrá una respuesta sensata. Podrías crear el cliente compatible con SMTP más perfecto, pero tu servidor web no hablará con él porque esta conversación se trata del protocolo compartido: no hay protocolo compartido, no hay alegría.

Es por eso que no puede implementar el protocolo HTTP sin implementar el protocolo HTTP; si lo que escribe no se ajusta al protocolo, entonces simplemente no es el protocolo, es otra cosa y no funcionará como se especifica en el protocolo

Si corremos con su ejemplo por un momento; donde el cliente se conecta y simplemente declara algo que se parece a una URL ... Y el servidor lo comprende y simplemente envía algo que se parece a HTML / JS (una página web), entonces, seguro, podría funcionar. ¿Qué salvaste sin embargo? ¿Un par de bytes al no decir GET? Pocos más en deshacerse de esos molestos encabezados ... El servidor también guardó algunos, pero ¿y si no puede resolver lo que le envió? ¿Qué pasa si solicitó una URL que terminó en JPEG y le envió algunos bytes que hacen una imagen, pero está en PNG? Un PNG incompleto en eso. Si tan solo tuviéramos un encabezado que dijera cuántos bytes eran ibapara enviar, entonces sabríamos si el número de bytes que recibimos era en realidad el archivo completo o no. ¿Qué pasa si el servidor comprime la respuesta para ahorrar algo de ancho de banda pero no te lo dice? Vas a gastar un considerable poder de cómputo tratando de resolver lo que envió.

Al final del día, necesitamos metainformación: información sobre información; necesitamos encabezados; Necesitamos archivos para tener nombres, extensiones, fechas creadas. Necesitamos que las personas tengan cumpleaños, que digan por favor y gracias, etc. El mundo está lleno de protocolos y fragmentos de información sobre el contexto, por lo que no tenemos que sentarnos y resolver todo desde cero todo el tiempo. Cuesta un poco de espacio de almacenamiento, pero vale la pena fácilmente

¿Realmente se necesita implementar varios métodos HTTP?

Podría decirse que uno no tiene que implementar todo el protocolo especificado, y esto suele ser cierto para cualquier cosa. No sé cada palabra en el idioma inglés; mi vecino chino también es desarrollador de software pero en una industria diferente y ni siquiera sabe chino para algunos de los términos utilizados en mi industria, y mucho menos el inglés. Sin embargo, lo bueno es que ambos podemos recoger un documento sobre la implementación de HTTP, él puede escribir el servidor y yo puedo escribir el cliente, en diferentes lenguajes de programación en diferentes arquitecturas, y aún funcionan porque se adhieren al protocolo

Bien puede ser el caso de que ninguno de sus usuarios emita otra cosa que no sea una solicitud GET, no usará conexiones persistentes, enviará nada más que JSON como el cuerpo, o necesitará aceptar otra cosa que no sea texto / sin formato para que pueda escriba un servidor web realmente reducido que solo cumpla con las demandas muy limitadas del navegador del cliente. Pero no podría simplemente decidir arbitrariamente eliminar las reglas básicas que hacen que "un texto que pasa por un socket" sea HTTP; no puede deshacerse de la noción básica de que la solicitud será una cadena como:

VERB URL VERSION
header: value

maybe_body

Y la respuesta tendrá una versión, un código de estado y quizás encabezados. Si cambia algo de eso, ya no es HTTP, es otra cosa, y solo funcionará con algo diseñado para comprenderlo. HTTP es lo que es por estas definiciones, por lo que si desea implementarlo, debe seguir las definiciones

Actualizar

Tu pregunta ha evolucionado un poco, aquí hay una respuesta a lo que preguntas:

¿Por qué el protocolo HTTP tiene noción de métodos?

Históricamente, debe apreciar que las cosas fueron mucho más inflexibles en su diseño e implementación, incluso en la medida en que no existían las secuencias de comandos e incluso la noción de que las páginas podrían ser dinámicas, generadas sobre la marcha en la memoria y empujadas hacia abajo. de ser un archivo estático en el disco que fue solicitado por el cliente y leído y empujado hacia abajo, no existía. Como tal, la primera web se centró en la noción de páginas estáticas que contenían enlaces a otras páginas, todas las páginas existían en el disco y la navegación habría sido realizada por el terminal en su mayoría haciendo solicitudes GET para páginas en URL, el servidor podría mapear la url a un archivo en el disco y enviarlo. También existía esta noción de que la red de documentos que se vinculaban entre sí y hacia otros lugares debería ser una evolución,

Eso proporciona un contexto histórico para los métodos: una vez, la URL era el bit inflexible, y se refería de manera simplista a las páginas en el disco, por lo que el método fue útil porque permitió al cliente describir qué intención tenía para el archivo y el servidor procesar el método de alguna manera variable. Realmente no existía la noción de que las URL fueran virtuales o se usaran para cambiar o mapear en la visión original de un hipertexto (y realmente era solo texto) web

No tengo la intención de que esta respuesta sea una documentación del registro histórico con fechas y referencias citadas de exactamente cuándo las cosas comenzaron a cambiar, para eso probablemente pueda leer Wikipedia, pero es suficiente decir que con el tiempo el deseo de web para obtener un mayor impulso y en cada extremo de la conexión servidor-cliente las oportunidades para crear una rica experiencia multimedia que estamos ampliando. Los navegadores admitieron una gran proliferación de etiquetas para formatear contenido, cada una de las cuales compitió para implementar características de riqueza de medios imprescindibles y nuevas formas de hacer que las cosas se vean elegantes.

Las secuencias de comandos llegaron al extremo del cliente y los complementos y extensiones del navegador, todo destinado a convertir el navegador en una fuente inagotable de gran capacidad para todo. Al final del servidor, la generación activa de contenido basado en algoritmos o datos de la base de datos fue el gran impulso y continúa desarrollándose en la medida en que probablemente ya haya pocos archivos en el disco, claro, mantenemos una imagen o un archivo de script como archivo en el servidor web y el navegador lo CONSIGUEN, pero cada vez más las imágenes que muestra el navegador y los scripts que ejecuta no son archivos que puede abrir en su explorador de archivos, son contenido generado que es el resultado de un proceso de compilación hecho a pedido , SVG que describe cómo dibujar píxeles en lugar de una matriz de píxeles de mapa de bits, o JavaScript que se emitió desde un script de nivel superior como TypeScript

Al crear páginas modernas de varios megabytes, probablemente solo una fracción del contenido ahora está fijo en un disco; Los datos de la base de datos están formateados y configurados en html que el navegador consumirá y el servidor lo hace en respuesta a múltiples rutinas de programación diferentes a las que la URL hace referencia de alguna manera

Mencioné en los comentarios a la pregunta que es un poco como un círculo completo. Cuando las computadoras costaban cientos de miles y las habitaciones ocupadas, era común permitir que varios usuarios usaran la unidad central central súper poderosa a través de cientos de terminales tontas: un teclado y un mouse, una pantalla verde, enviar texto, obtener algo enviar un mensaje de texto Con el tiempo, a medida que aumentaba la potencia de cómputo y bajaban los precios, la gente comenzó a terminar con computadoras de escritorio más potentes que los primeros mainframes y la capacidad de ejecutar aplicaciones potentes localmente, por lo que el modelo de mainframe quedó obsoleto. Sin embargo, nunca desapareció, porque las cosas simplemente evolucionaron para cambiar de sentido y volver a un servidor central que proporciona la mayor parte de la funcionalidad útil de la aplicación y cientos de computadoras cliente que hacen muy poco excepto dibujar en la pantalla, y enviar y recibir datos hacia / desde el servidor. Ese período intermedio en el que su computadora fue lo suficientemente inteligente como para ejecutar su propia copia de Word y Outlook al mismo tiempo, nuevamente ha dado paso a la oficina en línea, donde su navegador es un dispositivo para dibujar imágenes en la pantalla y editar el documento / correo electrónico reescribir como algo que vive en el servidor, se guarda allí, se envía y se comparte con otros usuarios, todo como la noción de que el navegador es solo un shell que proporciona una vista parcial en cualquier momento de esta cosa que vive en otro lugar

De las respuestas, tengo una idea de por qué existe el concepto de métodos ... Esto lleva a otra pregunta relacionada:

Por ejemplo, en el enlace de redacción de gmail, se enviarán la solicitud PUT / POST y los datos. ¿Cómo llega el navegador a saber qué método usar?

Utiliza GET de forma predeterminada, por convención / especificación, ya que eso es lo que se decretará que sucederá cuando escriba una url y presione Intro

¿La página de gmail enviada por el servidor incluye el nombre del método a utilizar cuando se llama a la solicitud de redacción de gmail?

Esta es una de las cosas clave a las que aludo en los comentarios anteriores. En la web moderna ya ni siquiera se trata de páginas. Una vez que las páginas eran archivos en el disco, que el navegador obtendría. Luego se convirtieron en páginas que se generaron predominantemente dinámicamente al insertar datos en una plantilla. Pero aún implicaba un proceso de "solicitar una nueva página del servidor, obtener una página, mostrar la página". El intercambio de páginas se volvió muy resbaladizo; no los viste cargar y cambiar el tamaño y sacudir su diseño para que pareciera más suave, pero aún así el navegador reemplazó una página completa o parte de una página con otra

La forma moderna de hacer las cosas es con una sola aplicación de página; el navegador tiene un documento en la memoria que se muestra de cierta manera, enviando scripts a thebservr y recupera un poco de información, y manipula el documento para que parte de la página cambie visualmente para mostrar la nueva información: todo funciona sin el navegador alguna vez carga otra página nueva; se ha convertido en una interfaz de usuario en la que partes de la misma se actualizan como una aplicación cliente típica, como Word o Outlook. Aparecen nuevos elementos encima de otros elementos y se pueden arrastrar alrededor de ventanas de diálogo de simulación, etc. Todo esto es el motor de secuencias de comandos del navegador que envía solicitudes utilizando cualquier método http que el desarrollador desee, recuperando datos y hurgando en el documento que el navegador está dibujando. Puede concebir que el navegador moderno es un dispositivo brillante que es algo así como un sistema operativo completo o una computadora virtual; Un dispositivo programable que tiene una forma bastante estandarizada de dibujar cosas en la pantalla, reproducir sonido, capturar la entrada del usuario y enviarla para su procesamiento. Todo lo que tiene que hacer para que dibuje su interfaz de usuario es proporcionarle un poco de html / css que crea una interfaz de usuario y luego ajustar el html constantemente para que el navegador cambie lo que está dibujando. Diablos, las personas están tan acostumbradas a ver el cambio de la barra de direcciones / usarlo como una dirección de intención que una aplicación de una sola página cambiará la URL programáticamente aunque no se esté navegando (solicitando páginas completamente nuevas) Todo lo que tiene que hacer para que dibuje su interfaz de usuario es proporcionarle un poco de html / css que crea una interfaz de usuario y luego ajustar el html constantemente para que el navegador cambie lo que está dibujando. Diablos, las personas están tan acostumbradas a ver el cambio de la barra de direcciones / usarlo como una dirección de intención que una aplicación de una sola página cambiará la URL programáticamente aunque no se esté navegando (solicitando páginas completamente nuevas) Todo lo que tiene que hacer para que dibuje su interfaz de usuario es proporcionarle un poco de html / css que crea una interfaz de usuario y luego ajustar el html constantemente para que el navegador cambie lo que está dibujando. Diablos, las personas están tan acostumbradas a ver el cambio de la barra de direcciones / usarlo como una dirección de intención que una aplicación de una sola página cambiará la URL programáticamente aunque no se esté navegando (solicitando páginas completamente nuevas)

cuando llamamos a www.gmail.com, debe estar usando el método GET, ¿cómo sabe el navegador que debe usar este método?

Cierto. Porque se especifica. La primera solicitud es como siempre ha sido históricamente: OBTENER un html inicial para dibujar una interfaz de usuario, luego pincharla y manipularla para siempre, u obtener otra página con otro script que pinche y manipule y cree una interfaz de usuario reactiva receptiva

Como dicen algunas respuestas, podemos crear nuevos usuarios en el método DELETE, y esto plantea dudas sobre la intención detrás de la noción de métodos en el protocolo http, porque al final del día, depende totalmente de los servidores a qué función quieren asignar una URL. . ¿Por qué el cliente debe decirle a los servidores qué métodos usar para una URL?

Historia. Legado. Teóricamente podríamos tirar todos los métodos http mañana: estamos en un nivel de sofisticación de programación donde los métodos son obsoletos porque las URL son procesables en la medida en que pueden ser el mecanismo de conmutación que indica al servidor que desea guardar los datos en el cuerpo como borrador de correo electrónico, o eliminar un borrador - no hay un archivo / emails / draft / save / 1234 en el servidor - el servidor está programado para seleccionar esa url y saber qué hacer con los datos del cuerpo - guardar como un borrador de correo electrónico con ID 1234

Por lo tanto, es posible eliminar los métodos, a excepción del enorme peso de la compatibilidad heredada que creció a su alrededor. Es mejor usarlos solo para lo que necesita, pero ignorarlos en gran medida y en su lugar usar lo que necesite para que su trabajo funcione. Todavía necesitamos métodos como los especificados porque debe recordar que significan algo para el navegador y el servidor sobre el cual hemos creado nuestras aplicaciones. La secuencia de comandos del lado del cliente quiere usar el navegador subyacente para enviar datos, necesita usar un método que haga que el navegador haga lo que le pide, probablemente una POST porque GET incluye toda su información variable en la URL y tiene un límite de longitud en muchos servidores El cliente desea una respuesta larga del servidor; no use un HEAD porque no se supone que tengan cuerpos de respuesta.

HTTP puede considerarse como un caso específico de principios genéricos de Llamada a procedimiento remoto: le dice al servidor lo que desea con algún campo variable en la solicitud, el servidor responde en consecuencia. En este momento, debido a la compleja interactividad de 'Web 2.0', estas mismas características se incluyen en todos los campos de la solicitud: la URL, los encabezados, el cuerpo y cada servidor de aplicaciones y aplicación los entiende a su manera. Sin embargo, originalmente la web era más simple, usaba páginas estáticas y se pensaba que los métodos HTTP proporcionaban el nivel de interactividad que sería suficiente. En particular, HTTP tiene muchos métodos que se usan raramente, si es que lo hacen, y algunos de ellos solo ven la luz gracias a REST. Por ejemplo, PUT y DELETE estaban moribundos antes de REST, y TRACE y PATCH aún no se han visto. La conclusión es que el modelo de RPC de HTTP no lo hizo

REST hizo exactamente lo contrario de lo que está proponiendo, al notar que los métodos HTTP sirven los casos de uso CRUD típicos de la mayoría de las aplicaciones si PUT y DELETE se recuperan.

Tenga en cuenta también que los métodos HTTP tienen semántica asignada, que son respetados por los navegadores y middleware como servidores proxy: las solicitudes POST, PUT, DELETE y PATCH pueden tener efectos secundarios y es probable que no sean idempotentes, por lo que las aplicaciones y middleware del lado del cliente deben tener cuidado no disparar estas solicitudes sin la acción expresa del usuario. En la práctica, las aplicaciones web mal diseñadas utilizaron GET para acciones no seguras y, por ejemplo, la captura previa de Google Web Accelerator causó problemas al eliminar un montón de datos en dichos sitios , por lo que su beta se suspendió poco después del lanzamiento.

Entonces, para responder a la pregunta '¿podemos?': Claro, solo necesita acordar un protocolo que le diga a la aplicación del servidor qué acción desea realizar, y luego coloca los argumentos en algún lugar de la URL / cuerpo, como el elemento objetivo para la acción. El conjunto de acciones está limitado solo por aplicaciones específicas, por lo que necesita un protocolo extensible. Pero deberá informar a las aplicaciones del cliente qué solicitudes son seguras y, probablemente, tener en cuenta otros matices, como el control de caché.

Desde mi punto de vista personal como desarrollador, puede facilitar la creación de puntos finales API. Por ejemplo, si escribo un controlador que gestiona productos en un sitio web, puedo usar la misma URL para realizar varias operaciones diferentes.

Ejemplos:

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

Esto obtendrá los detalles del producto 1234.

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

Esto creará un producto con ID 1234 usando datos en el cuerpo de la solicitud.

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

Esto actualizará el producto 1234 con datos en el cuerpo de la solicitud.

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

Esto eliminará un producto con ID 1234.

Podría hacer diferentes puntos finales para cada operación, pero eso complicaría el proceso y lo haría menos comprensible para otros desarrolladores.

¿Cuál es la necesidad de métodos como GET y POST en el protocolo HTTP?

Parece que olvidó los viejos tiempos cuando los servidores HTTP estaban allí solo para servir archivos ; no ejecuta script, CGI o crea contenido dinámico de ese tipo.

Los métodos de solicitud son un conjunto básico estandarizado de verbos sobre qué hacer con esos archivos ...

• OBTENER significa descargar
• HEAD significa obtener información de
• PUT significa subir
• ELIMINAR significa eliminar
• POST significa enviar datos a
• OPCIONES significa decirme qué podría hacer

En el día de HTTP / 0.9, la línea de solicitud es lo único en el tramo de solicitud del protocolo; sin encabezados de solicitud, sin encabezados de respuesta. Simplemente escriba GET /somefile, presione Enter, el servidor devolverá el cuerpo de la respuesta (es decir, contenido HTML), y está bien, gracias, adiós (es decir, cierre la conexión).

Si quisieras preguntarte por qué fue diseñado de esta manera ? Mi respuesta es porque se escribió originalmente para manejar el tipo de intercambio de contenido que existía en ese entonces , es decir, el servicio de archivos HTML estáticos a pedido de los usuarios.

Sin embargo, si quería preguntar cómo tratar estas semánticas en el servidor de aplicaciones moderno ...

¿No podemos implementar el protocolo HTTP usando solo un cuerpo de solicitud y un cuerpo de respuesta?

¿Realmente se necesita implementar varios métodos HTTP?

Mi respuesta es: haga lo que quiera hacer, pero tenga en cuenta que no debe implementar la lógica de la aplicación de una manera que desafíe las expectativas del protocolo : las expectativas como GET no deberían cambiar los datos (o muy libremente, tienen al menos un resultado idempotente) ), HEAD debe tener el mismo resultado que GET pero sin cuerpo de respuesta, PUT debe hacer que el contenido del URI de destino esté disponible (si tiene éxito).

Si va en contra de las expectativas sin considerar cuidadosamente sus implicaciones , sucederían varias cosas desagradables, como ...

• Cuando calza el método GET en el uso de envío de datos, el servidor puede escupir 414 error " URI demasiado largo " en su cara.
• Cuando calza el método GET en el uso de modificación de datos, encontrará que la modificación a veces no se realiza cuando el usuario está detrás de un proxy de almacenamiento en caché, o se producirían modificaciones inesperadas cuando el usuario recupera la URL del marcador (o cuando los rastreadores web lo alcanzan) .
• Cuando responde incorrectamente al método HEAD, descubrirá que sus herramientas de verificación automática del sitio (por ejemplo wget --spider) rescatan en su sitio.
• Cuando calzas el método POST en la descarga de contenido, encontrarás que los marcadores o incluso ingresar la URL en el navegador no funcionarán.
• Y muchos más...

"El principiante conoce las reglas, pero los veteranos conocen las excepciones " .

De todos modos, puede terminar encontrando algunas excusas válidas para ir en contra de algunas de las reglas para algunos casos de uso restringido; pero asegúrese de investigar y considerar todas las posibilidades. De lo contrario, terminará eliminando la interoperabilidad y arruinando las "experiencias del usuario".

No hay garantía de que los usuarios usen siempre el último despliegue brillante de los principales clientes / agentes de usuario de marca que usted probó. Pueden usar una marca local que se adapte a sus necesidades (incluido yo), una personalizada que pidieron en la tienda especializada de al lado o una vintage que extrajeron de un almacén. Incluso con todo esto, se espera que sus sitios brinden un servicio razonable. Esa es una razón por la que tenemos estándares.

Romper descuidadamente el estándar también significa que está aplicando discriminación a sus usuarios.

Es cierto que en teoría podríamos usar get over the place y funcionaría de alguna manera. Algunos programas incluso usan GET con el cuerpo de la solicitud (te estoy mirando elasticsearch / kibana). Esto, por supuesto, es algo horrible.

La razón más importante es porque los diferentes métodos tienen una semántica diferente. Algunos son seguros, algunos son idempotentes. Algunos son los dos. Ver cuales son cuales

Esto es importante, por ejemplo, al interactuar con otras aplicaciones. Se supone que los puntos finales GET no tienen efectos secundarios. Esto es importante cuando Google está rastreando tu lado. Se supone que PUT es idempotente, lo que significa que el cliente puede volver a intentarlo en caso de falla. Este no es el caso de POST, por lo que los navegadores deben tener un cuadro de confirmación feo si presiona f5 en una solicitud de publicación.

Vea lo que puede suceder si usa GET donde debería haber usado POST

También puede pensar en GET, POST, etc. como sobrecargas de la misma función, o incluso como captadores y establecedores.

GET_MyVar() no tomará un parámetro de entrada (también conocido como el Cuerpo de solicitud), pero devuelve algo.

POST_MyVar(string blah)hace algo con la entrada (nuevamente, el cuerpo de la solicitud) y puede devolver algo. (¡También necesita al menos devolver un código de respuesta, para que sepamos que la función se ejecutó!)

DELETE_MyVar() Además, probablemente no tome nada y se espera eliminar algo.

Sí, podríamos implementarlo todo con:
MyVar(string Action, string? blah)

De esta manera, podríamos aceptar una sola llamada y luego elegir qué hacer en función de algún otro parámetro.

Pero una de las ventajas de este enfoque es que permite a los navegadores y servidores optimizar la forma en que funcionan estas cosas. Por ejemplo, tal vez el servidor quiera bloquear todas las solicitudes donde Action==DELETE. Tal vez los navegadores quieran almacenar en caché cosas donde, Action==GET.si no, en cada función tendríamos que escribirif (Action==Delete) {return AngryFace}

No es necesario implementar todo exactamente de acuerdo con el protocolo, pero el protocolo es básicamente un conjunto de reglas que todos decidimos seguir. De esa manera, puedo adivinar fácilmente qué hará su sitio, ¡incluso si no he visto el servidor!

Los métodos HTTP tienen diferentes propósitos. En general, GETes para descargas y POSTes para cargas.

La única forma de implementar parte del protocolo HTTP usando solo un cuerpo de solicitud y un cuerpo de respuesta sería implementarlo POST. GETno tiene un cuerpo de solicitud. Solo tiene la solicitud en sí con encabezados, pero no tiene cuerpo. Es solo una solicitud de descarga de un documento. POSTtiene tanto el cuerpo de la solicitud (la carga del archivo) como el cuerpo de la respuesta (el documento que muestra el resultado).

Entonces, ¿podría simplemente implementar POSTy terminar? No si desea que su sitio sea utilizable en navegadores estándar. El tipo de solicitud predeterminado que envían los navegadores es GET. POSTPor lo general, las solicitudes solo se envían cuando se envían formularios en páginas web o para llamadas AJAX. Solo si este servidor en particular solo se usara para llamadas AJAX, y no para páginas visibles para los usuarios, solo podría salirse con la suya POST.

Los navegadores a veces también envían HEADsolicitudes para verificar si un documento ha cambiado desde la última vez que lo descargaron, por lo que sería recomendable al menos implementarlo también.

En cualquier caso, no hay una buena razón para implementar un servidor web para su sitio desde cero. El protocolo HTTP es complicado. Además de los diversos métodos, también tendría que implementar canalizaciones y solicitudes fragmentadas. Es mucho más fácil construir su aplicación web sobre un servidor web como Apache, Nginx o IIS que maneja el protocolo HTTP por usted. Usted menciona Servlets, por lo que tal vez debería usar servidores web Tomcat o JBoss que ejecutan Servlets.

Tienes razón, podríamos hacer eso, GET, POST, PUT, etc. son solo convenciones históricas si tuviera mi camino HTTP sería reemplazado con solo el método POST y nada más, aunque tengo que admitir que eliminar GET sería una gran empresa, eso no se pudo hacer, el caballo ya se había echado encima

Su protocolo propuesto sería significativamente menos seguro contra los piratas informáticos.

Hay una razón por la cual los sitios web se han alejado del almacenamiento de información sobre variables y demás en la URL, y esa razón es simple: les brinda a los atacantes una forma muy simple de atacar su sistema. Al observar la información de URL de texto sin formato, pueden determinar la manera en que se construyen los datos enviados a su servidor web; luego pueden usar esta información para ejecutar un ataque a su servidor mediante el uso de una URL especialmente diseñada que les permite inyectar código o datos maliciosos en su servidor.