HTTP GET con cuerpo de solicitud

Estoy desarrollando un nuevo servicio web RESTful para nuestra aplicación.

Al hacer un GET en ciertas entidades, los clientes pueden solicitar el contenido de la entidad. Si desean agregar algunos parámetros (por ejemplo, ordenar una lista), pueden agregar estos parámetros en la cadena de consulta.

Alternativamente, quiero que las personas puedan especificar estos parámetros en el cuerpo de la solicitud. HTTP / 1.1 no parece prohibir esto explícitamente. Esto les permitirá especificar más información, podría facilitar la especificación de solicitudes XML complejas.

Mis preguntas:

• ¿Es esta una buena idea por completo?
• ¿Tendrán problemas los clientes HTTP con el uso de cuerpos de solicitud dentro de una solicitud GET?

http://tools.ietf.org/html/rfc2616

Comentario de Roy Fielding sobre incluir un cuerpo con una solicitud GET .

Si. En otras palabras, cualquier mensaje de solicitud HTTP puede contener un cuerpo de mensaje y, por lo tanto, debe analizar los mensajes con eso en mente. Sin embargo, la semántica del servidor para GET está restringida de modo que un cuerpo, si lo hay, no tiene un significado semántico para la solicitud. Los requisitos sobre el análisis son independientes de los requisitos sobre la semántica de métodos.

Entonces, sí, puede enviar un cuerpo con GET, y no, nunca es útil hacerlo.

Esto es parte del diseño en capas de HTTP / 1.1 que se volverá a aclarar una vez que se particione la especificación (trabajo en progreso).

.... Roy

Sí, puede enviar un cuerpo de solicitud con GET pero no debería tener ningún significado. Si le da sentido al analizarlo en el servidor y cambiar su respuesta en función de su contenido , entonces está ignorando esta recomendación en la especificación HTTP / 1.1, sección 4.3 :

[...] si el método de solicitud no incluye una semántica definida para un cuerpo de entidad, entonces el cuerpo del mensaje DEBE ignorarse al manejar la solicitud.

Y la descripción del método GET en la especificación HTTP / 1.1, sección 9.3 :

El método GET significa recuperar cualquier información ([...]) identificada por el URI de solicitud.

que establece que el cuerpo de la solicitud no es parte de la identificación del recurso en una solicitud GET, solo el URI de la solicitud.

Actualización El RFC2616 al que se hace referencia como "especificación HTTP / 1.1" ahora está obsoleto. En 2014 fue reemplazado por RFC 7230-7237. Se ha eliminado la cita "el cuerpo del mensaje DEBE ignorarse al manejar la solicitud". Ahora es solo "La estructura de mensajes de solicitud es independiente de la semántica del método, incluso si el método no define ningún uso para un cuerpo de mensaje" La segunda cita "El método GET significa recuperar cualquier información ... identificada por el URI de solicitud" fué borrado. - De un comentario

Si bien puede hacerlo, en la medida en que no esté explícitamente excluido por la especificación HTTP, sugeriría evitarlo simplemente porque la gente no espera que las cosas funcionen de esa manera. Hay muchas fases en una cadena de solicitud HTTP y, si bien "en su mayoría" se ajustan a la especificación HTTP, lo único seguro es que se comportarán como los navegadores web utilizan tradicionalmente. (Estoy pensando en cosas como proxies transparentes, aceleradores, kits de herramientas de A / V, etc.)

Este es el espíritu detrás del Principio de Robustez: "sé liberal en lo que aceptas y conservador en lo que envías", no quieres empujar los límites de una especificación sin una buena razón.

Sin embargo, si tiene una buena razón, hágalo.

Es probable que encuentre problemas si alguna vez intenta aprovechar el almacenamiento en caché. Los proxies no van a mirar en el cuerpo GET para ver si los parámetros tienen un impacto en la respuesta.

Ni restclient ni la consola REST lo admiten, pero curl sí.

La especificación HTTP dice en la sección 4.3

Un cuerpo de mensaje NO DEBE incluirse en una solicitud si la especificación del método de solicitud (sección 5.1.1) no permite enviar un cuerpo de entidad en las solicitudes.

La sección 5.1.1 nos redirige a la sección 9.x para los diversos métodos. Ninguno de ellos prohíbe explícitamente la inclusión de un cuerpo de mensaje. Sin embargo...

La sección 5.2 dice

El recurso exacto identificado por una solicitud de Internet se determina examinando tanto el campo URI de solicitud como el campo de encabezado de host.

y la Sección 9.3 dice

El método GET significa recuperar cualquier información (en forma de entidad) identificada por el URI de solicitud.

Lo que en conjunto sugiere que cuando se procesa una solicitud GET, no se requiere que un servidor examine nada más que el campo URI de solicitud y encabezado de host.

En resumen, la especificación HTTP no le impide enviar un cuerpo de mensaje con GET, pero hay suficiente ambigüedad que no me sorprendería si no fuera compatible con todos los servidores.

Elasticsearch acepta solicitudes GET con un cuerpo. Incluso parece que esta es la forma preferida: guía Elasticsearch

Algunas bibliotecas de clientes (como el controlador Ruby) pueden registrar el comando cry en stdout en modo de desarrollo y está utilizando esta sintaxis ampliamente.

Lo que está tratando de lograr se ha hecho durante mucho tiempo con un método mucho más común, y uno que no depende del uso de una carga útil con GET.

Simplemente puede crear su tipo de medio de búsqueda específico, o si desea ser más RESTful, use algo como OpenSearch y PUBLIQUE la solicitud al URI que el servidor le indicó, digamos / search. El servidor puede generar el resultado de búsqueda o construir el URI final y redirigir usando un 303.

Esto tiene la ventaja de seguir el método PRG tradicional, ayuda a los intermediarios de caché a almacenar los resultados, etc.

Dicho esto, los URI se codifican de todos modos para cualquier cosa que no sea ASCII, y también lo son application / x-www-form-urlencoded y multipart / form-data. Recomiendo usar esto en lugar de crear otro formato json personalizado si su intención es admitir escenarios ReSTful.

Puedes enviar un GET con un cuerpo o enviar un POST y renunciar a la religiosidad RESTish (no es tan malo, hace 5 años solo había un miembro de esa fe: sus comentarios se vincularon anteriormente).

Tampoco son buenas decisiones, pero enviar un cuerpo GET puede evitar problemas para algunos clientes y algunos servidores.

Hacer una POST puede tener obstáculos con algunos marcos RESTish.

Julian Reschke sugirió anteriormente usar un encabezado HTTP no estándar como "BÚSQUEDA" que podría ser una solución elegante, excepto que es aún menos probable que sea compatible.

Puede ser más productivo enumerar clientes que pueden y no pueden hacer cada uno de los anteriores.

Clientes que no pueden enviar un GET con cuerpo (que yo sepa):

• XmlHTTPRequest Fiddler

Clientes que pueden enviar un GET con cuerpo:

• la mayoría de los navegadores

Servidores y bibliotecas que pueden recuperar un cuerpo de GET:

• apache
• PHP

Servidores (y servidores proxy) que despojan a un cuerpo de GET:

• ?

Le hice esta pregunta al IETF HTTP WG. El comentario de Roy Fielding (autor del documento http / 1.1 en 1998) fue que

"... se rompería una implementación para hacer algo más que analizar y descartar ese cuerpo si se recibe"

RFC 7213 (HTTPbis) establece:

"Una carga útil dentro de un mensaje de solicitud GET no tiene una semántica definida".

Parece claro ahora que la intención era que el significado semántico en los cuerpos de solicitud GET está prohibido, lo que significa que el cuerpo de la solicitud no puede usarse para afectar el resultado.

Hay representantes que definitivamente romperán su solicitud de varias maneras si incluye un cuerpo en GET.

En resumen, no lo hagas.

¿Qué servidor lo ignorará? - fijiaaron 30 de agosto de 12 a 21:27

Google, por ejemplo, está peor que ignorarlo, ¡lo considerará un error !

Pruébelo usted mismo con un simple netcat:

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

(el contenido de 1234 es seguido por CR-LF, por lo que es un total de 6 bytes)

y obtendrás:

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

También obtienes 400 Bad Request de Bing, Apple, etc. que son atendidos por AkamaiGhost.

Por lo tanto, no recomendaría usar solicitudes GET con una entidad del cuerpo.

De RFC 2616, sección 4.3 , "Cuerpo del mensaje":

Un servidor DEBE leer y reenviar un cuerpo de mensaje en cualquier solicitud; si el método de solicitud no incluye una semántica definida para un cuerpo de entidad, entonces el cuerpo del mensaje DEBE ignorarse al manejar la solicitud.

Es decir, los servidores siempre deben leer cualquier cuerpo de solicitud proporcionado de la red (verifique Content-Length o lea un cuerpo fragmentado, etc.). Además, los representantes deben reenviar cualquier cuerpo de solicitud que reciban. Luego, si el RFC define la semántica para el cuerpo para el método dado, el servidor puede usar el cuerpo de la solicitud para generar una respuesta. Sin embargo, si el RFC no define la semántica para el cuerpo, entonces el servidor debería ignorarlo.

Esto está en línea con la cita de Fielding anterior.

La Sección 9.3 , "GET", describe la semántica del método GET y no menciona los cuerpos de solicitud. Por lo tanto, un servidor debe ignorar cualquier cuerpo de solicitud que reciba en una solicitud GET.

Según XMLHttpRequest, no es válido. De la norma :

4.5.6 El send()método

client . send([body = null])

Inicia la solicitud. El argumento opcional proporciona el cuerpo de la solicitud. El argumento se ignora si el método de solicitud es GETo HEAD.

Lanza una InvalidStateErrorexcepción si alguno de los estados no se abre o si send()se establece el indicador.

El método debe ejecutar estos pasos:send(body)

1. Si el estado no está abierto , arroje una InvalidStateErrorexcepción.
2. Si send()se establece la bandera, lanzar una InvalidStateErrorexcepción.
3. Si el método de solicitud es GETo HEAD, establezca el cuerpo en nulo.
4. Si el cuerpo es nulo, vaya al siguiente paso.

Aunque, no creo que deba, porque la solicitud GET podría necesitar un gran contenido corporal.

Entonces, si confía en XMLHttpRequest de un navegador, es probable que no funcione.

Si realmente desea enviar un cuerpo JSON / XML almacenable en caché a la aplicación web, el único lugar razonable para colocar sus datos es una cadena de consulta codificada con RFC4648: codificación Base 64 con URL y alfabeto seguro de nombre de archivo . Por supuesto, podría simplemente urlencode JSON y poner en el valor del parámetro de URL, pero Base64 da un resultado más pequeño. Tenga en cuenta que existen restricciones de tamaño de URL, consulte ¿Cuál es la longitud máxima de una URL en diferentes navegadores? .

Puede pensar que el =carácter de relleno de Base64 puede ser malo para el valor de parámetro de URL, sin embargo, parece que no; consulte esta discusión: http://mail.python.org/pipermail/python-bugs-list/2007-February/037195.html . Sin embargo, no debe colocar datos codificados sin el nombre de parámetro porque la cadena codificada con relleno se interpretará como clave de parámetro con valor vacío. Me gustaría utilizar algo así como ?_b64=<encodeddata>.

No recomendaría esto, va en contra de las prácticas estándar y no ofrece mucho a cambio. Desea conservar el cuerpo para el contenido, no para las opciones.

¿Qué pasa con los encabezados codificados base64 no conformes? "ALGUNOS PARAMS DE APLICACIÓN: sdfSD45fdg45 / aS"

Restricciones de longitud hm. ¿No puedes hacer que tu manejo POST distinga entre los significados? Si desea parámetros simples como la ordenación, no veo por qué esto sería un problema. Supongo que es certeza lo que te preocupa.

Estoy molesto porque REST ya que el protocolo no admite OOP y el Getmétodo es una prueba. Como solución, puede serializar su DTO a JSON y luego crear una cadena de consulta. En el lado del servidor, podrá deserializar la cadena de consulta al DTO.

Echa un vistazo a:

• Diseño basado en mensajes en ServiceStack
• Creación de servicios web basados ​​en mensajes RESTful con WCF

El enfoque basado en mensajes puede ayudarlo a resolver la restricción del método Get. Podrá enviar cualquier DTO como con el cuerpo de la solicitud

El marco del servicio web Nelibur proporciona una funcionalidad que puede usar

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

Por ejemplo, funciona con Curl, Apache y PHP.

Archivo PHP:

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

Comando de consola:

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

Salida:

GET
{"the": "body"}

En mi humilde opinión, puede enviar el JSONcodificado (es decir encodeURIComponent) en el URL, de esta manera no viola las HTTPespecificaciones y lleva su JSONal servidor.

Tiene una lista de opciones que son mucho mejores que usar un cuerpo de solicitud con GET.

Supongamos que tiene categorías y elementos para cada categoría. Ambos serán identificados por una identificación ("catid" / "itemid" por el bien de este ejemplo). Desea ordenar de acuerdo con otro parámetro "sortby" en un "orden" específico. Desea pasar parámetros para "sortby" y "order":

Usted puede:

1. Use cadenas de consulta, p. Ej. example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc
2. Use mod_rewrite (o similar) para las rutas: example.com/category/{catid}/item/{itemid}/{sortby}/{order}
3. Utilice encabezados HTTP individuales que pase con la solicitud
4. Utilice un método diferente, por ejemplo, POST, para recuperar un recurso.

Todos tienen sus desventajas, pero son mucho mejores que usar un GET con un cuerpo.

Incluso si una herramienta popular usa esto, como se cita frecuentemente en esta página, creo que sigue siendo una mala idea, ya que es demasiado exótica, a pesar de que no está prohibida por la especificación.

Muchas infraestructuras intermedias pueden simplemente rechazar tales solicitudes.

Por ejemplo, olvidarse de utilizar algunos de los CDN disponible en frente de su sitio web, como este uno :

Si una GETsolicitud del espectador incluye un cuerpo, CloudFront devuelve un código de estado HTTP 403 (Prohibido) al espectador.

Y sí, es posible que las bibliotecas de sus clientes tampoco admitan la emisión de tales solicitudes, como se informa en este comentario .

Estoy usando el RestTemplate de Spring Framework en mi programa cliente y, en el lado del servidor, definí una solicitud GET con un cuerpo Json. Mi propósito principal es el mismo que el suyo: cuando la solicitud tiene numerosos parámetros, ponerlos en el cuerpo parece más ordenado que ponerlos en la cadena de URI prolongada. ¿Si?

Pero, lamentablemente, ¡no está funcionando! El lado del servidor lanzó la siguiente excepción:

org.springframework.http.converter.HttpMessageNotReadableException: falta el cuerpo de solicitud requerido ...

Pero estoy bastante seguro de que el código del cliente proporciona correctamente el cuerpo del mensaje, entonces, ¿qué pasa?

Seguí el método RestTemplate.exchange () y encontré lo siguiente:

// SimpleClientHttpRequestFactory.class
public class SimpleClientHttpRequestFactory implements ClientHttpRequestFactory, AsyncClientHttpRequestFactory {
    ...
    protected void prepareConnection(HttpURLConnection connection, String httpMethod) throws IOException {
        ...
        if (!"POST".equals(httpMethod) && !"PUT".equals(httpMethod) && !"PATCH".equals(httpMethod) && !"DELETE".equals(httpMethod)) {
            connection.setDoOutput(false);
        } else {
            connection.setDoOutput(true);
        }
        ...
    }
}

// SimpleBufferingClientHttpRequest.class
final class SimpleBufferingClientHttpRequest extends AbstractBufferingClientHttpRequest {
    ...
    protected ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        ...
        if (this.connection.getDoOutput() && this.outputStreaming) {
            this.connection.setFixedLengthStreamingMode(bufferedOutput.length);
        }

        this.connection.connect();
        if (this.connection.getDoOutput()) {
            FileCopyUtils.copy(bufferedOutput, this.connection.getOutputStream());
        } else {
            this.connection.getResponseCode();
        }
        ...
    }
}

Tenga en cuenta que en el método executeInternal (), el argumento de entrada 'bufferedOutput' contiene el cuerpo del mensaje proporcionado por mi código. Lo vi a través del depurador.

Sin embargo, debido a prepareConnection (), getDoOutput () en executeInternal () siempre devuelve falso, lo que a su vez hace que el bufferedOutput sea completamente ignorado. No se copia en la secuencia de salida.

En consecuencia, mi programa de servidor no recibió el cuerpo del mensaje y lanzó esa excepción.

Este es un ejemplo sobre el RestTemplate del marco Spring. El punto es que, incluso si el cuerpo del mensaje ya no está prohibido por la especificación HTTP, algunas bibliotecas o marcos de clientes o servidores aún pueden cumplir con la especificación anterior y rechazar el cuerpo del mensaje de la solicitud GET.