El Comité de Ingeniería de Internet (IETF), encargado del desarrollo de protocolos y arquitectura de la red Internet, ha otorgado al método QUERY del HTTP el estatus de «Borrador de estándar» y ha publicado la especificación relacionada RFC 10008. El método QUERY, en cuanto a la forma de enviar datos al servidor, se asemeja al método POST, pero se diferencia en que no está orientado a la escritura de datos y cambios de estado, sino a la formulación de solicitudes de lectura.
En cuanto a las tareas a resolver, el nuevo método es similar al GET y permite enviar solicitudes que pueden ser repetidas o reiniciadas sin modificar el estado en el servidor. Al igual que en el método POST, los parámetros de la solicitud en QUERY se transmiten no en el URI, sino en el cuerpo de la solicitud. Este enfoque permite enviar grandes volúmenes de parámetros en la solicitud, superando el límite de tamaño de parámetros del método GET (8000 bytes).
GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
Host: example.org
QUERY /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
q=foo&limit=10&sort=-published
Los parámetros enviados a través del método QUERY no se reflejan en los registros servidores, lo que, por un lado, dificulta el análisis de solicitudes y la diagnosis de problemas, pero, por otro lado, brinda la posibilidad de ocultar datos confidenciales de los registros de los servidores proxy.
Entre las áreas de aplicación del método QUERY se menciona el envío de solicitudes a Web APIs, que devuelven resultados en formato JSON o XML, o backends que generan contenido. Para determinar la posibilidad de utilizar el nuevo método al hacer una solicitud a servidor se propone utilizar el método OPTIONS, y para determinar los formatos soportados, el método HEAD:
> OPTIONS /contacts HTTP/1.1
> Host: example.org
HTTP/1.1 200 OK
Allow: GET, QUERY, OPTIONS, HEAD
En el método QUERY se prevé soporte para el caché: los servidores proxy o manejadores pueden guardar el resultado de la ejecución de la solicitud, asignarle un URI para futuras solicitudes a través del método GET y devolver información sobre la entrega de la versión en caché a través del encabezado «Last-Modified». Para verificar la existencia de cambios desde la última solicitud, se puede usar el encabezado «If-Modified-Since». Para indicar alternativas de ejecución de la solicitud, los encabezados «Content-Location» y «Location» pueden indicarse en la respuesta, donde la diferencia es que el primero transmite un enlace para obtener el resultado de una solicitud previamente ejecutada, mientras que el segundo está destinado a repetir la solicitud con los mismos parámetros.
> QUERY /contacts HTTP/1.1
> Host: example.org
> Content-Type: application/x-www-form-urlencoded
> Aceptar: application/json
> selecciona=apellido,nombre,email&limite=10&coincidencia="email=*@example.*"
HTTP/1.1 200 OK
Tipo de contenido: application/json
Ubicación del contenido: /contactos/resultados-almacenados/17
Ubicación: /contactos/consultas-almacenadas/42
Última modificación: sáb, 25 ago 2012 23:34:45 GMT
Fecha: dom, 17 nov 2024, 16:10:24 GMT
> GET /contactos/resultados-almacenados/17 HTTP/1.1
> Host: example.org
> Aceptar: application/json
Además del tipo «application/x-www-form-urlencoded», también se pueden utilizar formatos extendidos para transmitir parámetros en las solicitudes de QUERY, como JSONPath (application/jsonpath), XSLT (application/xslt+xml) y SQL (application/sql). Los formatos compatibles se devuelven el servidor en el encabezado Accept-Query.
> HEAD /contactos HTTP/1.1
> Host: example.org
HTTP/1.1 200 OK
Tipo de contenido: application/xhtml
Aceptación-Consulta: application/x-www-form-urlencoded, application/jsonpath, application/sql
> QUERY /errata.json HTTP/1.1
> Host: example.org
> Tipo de contenido: application/jsonpath
> Aceptar: application/json
>
> $..[
> ?@.código_estado_errata==»Rechazado»
> && @.fecha_presentación>»2024″
> ]
> [«id-doc»]
Fuente: opennet.ru
