Semántica y limitaciones de HTTP GET y POST

Question

A principios de esta semana, tuve que hacer algo que parece una violación a la semántica. Dejame explicar.

que estaba haciendo una sencilla aplicación cliente AJAX, que era hacer una petición a un servicio con un determinado número de parámetros. Como toda la aplicación es básicamente de solo lectura, pensé que usar HTTP GET era el camino a seguir. Algunos de los parámetros que tuve que pasar eran simples (como el orden de clasificación o el número de página).

Sin embargo, uno de los parámetros requeridos podría ser de longitud variable, y esto me preocupaba. Como estaba codificando todos los parámetros en la cadena de consulta de la solicitud GET, me pareció que esto colocaba un upper limit of (roughly) 2000 characters for the request URL innecesario. Y a pesar de eso, no me gustó ver URLs de solicitud de 500 caracteres.

Por lo tanto, ya que una solicitud POST no tiene una limitación de esa manera, me decidí a cambiar. Pero esto no se siente bien. Tengo la impresión de que un POST denota modificación de datos, pero lo estoy usando para una simple solicitud de solo lectura.

¿Hay una mejor manera de hacerlo? Para realizar un GET, con muchos parámetros? He oído hablar de un método: donde realiza un POST preliminar de los parámetros , y luego realiza un GET. Pero esta técnica deja mucho que desear.

Pero mirando más allá de este caso concreto, lo son la semántica reales y las limitaciones de los métodos de petición HTTP? ¿Y por qué GET no admite ningún tipo de carga útil de parámetro? Usar la cadena de consulta en la URL casi me parece un truco.

Answer 1

algunos puntos sobre este tema:

• La especificación HTTP (RFC 2616) no forbit peticiones GET para tener parámetros, así que no es una cuestión de la semántica de HTTP GET en sí. Sin embargo, muchas pilas HTTP (para clientes, servicios o servidores proxy) prohíben los cuerpos en las peticiones HTTP, el hecho de que no se puede usarlos es en su mayoría un detalle de implementación (bastante frecuente) que una cuestión semántica con el HTTP GET solicita
• Del mismo modo, la limitación de la longitud de URI (o cadena de consulta) tampoco se especifica en el RFC. Es principalmente una mitigación de seguridad implementada por varias pilas de servidores HTTP para evitar que un cliente malo consuma recursos del servidor (por ejemplo, en IIS/ASP.NET el límite predeterminado es 2k pero puede aumentarlo a través de algunos elementos en web.config). Nuevamente, no es una cuestión semántica sino práctica.
• Las solicitudes POST indican la modificación de datos si está siguiendo la filosofía REST, pero hay muchos ejemplos de solicitudes HTTP POST usadas para operaciones de solo lectura. SOAP utiliza POST en todas sus solicitudes, independientemente de si la operación que está llamando es "segura" o "modificante". Entonces puedes usar POST para esas operaciones también. Sin embargo, al desviarse del uso de REST (y del HTTP "canónico"), perderá algunas de las características del protocolo, como el almacenamiento en caché, que se puede aplicar a solicitudes GET, pero no a POST.
• Su ejemplo de usar dos solicitudes (POST con parámetros + GET para "obtener" los resultados) parece excesivo. Como mencioné, las solicitudes POST no necesariamente significan la modificación de recursos, por lo que no es necesario crear un nuevo "protocolo" (POST + GET) para acceder a su operación cuando una solicitud es suficiente.