metodos - spring rest http methods

Carga de los métodos de solicitud HTTP (3)

Aquí está el resumen de RFC 7231 , una versión actualizada del enlace @Darrel publicado:

CABEZA - Sin semántica definida del cuerpo.
GET - Sin semántica definida del cuerpo.
PUT - Cuerpo compatible.
POST - Cuerpo compatible.
ELIMINAR - Sin semántica definida del cuerpo.
TRACE - Cuerpo no compatible.
OPCIONES : Soporte del cuerpo pero no semántica en el uso (tal vez en el futuro).
CONNECT - Sin semántica definida del cuerpo

Como @John también mencionó, todos los métodos de solicitud admiten cadenas de consulta en la URL (una excepción notable podría ser OPTIONS que solo parece ser útil [en mis pruebas] si la URL es HOST/* ).

No he probado los métodos CONNECT y PATCH porque no tengo ningún interés en ellos ATM.

La entrada de Wikipedia en HTTP enumera los siguientes métodos de solicitud HTTP:

HEAD: solicita una respuesta idéntica a la que correspondería a una solicitud GET, pero sin el cuerpo de respuesta.
OBTENER: solicita una representación del recurso especificado.
POST: Envía datos para ser procesados (por ejemplo, desde un formulario HTML) al recurso identificado. Los datos están incluidos en el cuerpo de la solicitud.
PUT: carga una representación del recurso especificado.
ELIMINAR: borra el recurso especificado.
RASTREO: Hace eco de la solicitud recibida, de modo que un cliente pueda ver qué cambios (si los hubo) o si los servidores intermedios han realizado adiciones.
OPCIONES: Devuelve los métodos HTTP que el servidor admite para la URL especificada. Esto se puede usar para verificar la funcionalidad de un servidor web al solicitar ''*'' en lugar de un recurso específico.
CONNECT: convierte la conexión de solicitud en un túnel TCP / IP transparente, por lo general para facilitar la comunicación encriptada con SSL (HTTPS) a través de un proxy HTTP no encriptado.
PATCH: se usa para aplicar modificaciones parciales a un recurso.

Me interesa saber (específicamente sobre los primeros cinco métodos):

¿Cuál de estos métodos puede (se supone que?) recibir cargas útiles
- de los métodos que pueden recibir cargas útiles, ¿cómo lo reciben?
  - a través de la cadena de consulta en la URL?
  - a través de un cuerpo codificado en URL?
  - a través del cuerpo crudo / fragmentado?
  - a través de una combinación de ([todos / algunos] de) lo anterior?

Aprecio toda la contribución, si pudieras compartir algo de lectura (preferiblemente ligera) que también sería genial.

Estoy bastante seguro de que no está claro si las solicitudes GET pueden tener cargas útiles. Las solicitudes GET generalmente publican datos de formulario a través de la cadena de consulta, lo mismo para las solicitudes HEAD. HEAD es esencialmente GET, excepto que no quiere un cuerpo de respuesta.

(Nota al margen: digo que no está claro porque una solicitud GET podría actualizarse técnicamente a otro protocolo, de hecho, una versión de websockets hizo justamente esto, y aunque algún software de proxy funcionó bien, otros se estremecieron con el apretón de manos).

POST generalmente tiene un cuerpo. Nada le impide utilizar una cadena de consulta, pero el cuerpo POST generalmente contendrá datos de formulario en una POST.

Para obtener más información (y más detallada), accedería a las especificaciones HTTP / 1.1 .

RFC 7231 , HTTP 1.1 Semántica y contenido, es la fuente más actualizada y autorizada sobre la semántica de los métodos HTTP. Esta especificación dice que no hay un significado definido para una carga útil que pueda incluirse en un mensaje GET, HEAD, OPTIONS o CONNECT. La Sección 4.3.8 dice que el cliente no debe enviar un cuerpo para una solicitud TRACE. Por lo tanto, solo TRACE no puede tener una carga útil, pero GET, HEAD, OPTIONS y CONNECT probablemente no lo harán y no se espera que el servidor sepa cómo manejarlo si el cliente envía uno (lo que significa que puede ignorarlo).

Si cree que algo es ambiguo, entonces hay una lista de correo donde puede expresar sus inquietudes.