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.