203 votos

POST HTTP con parámetros de consulta de URL ¿buena idea o no?

Estoy diseñando una API para ir sobre HTTP y me pregunto si usar el comando HTTP POST, pero con parámetros de consulta de URL solamente y sin el cuerpo de la petición, es una buena forma de hacerlo.

Consideraciones:

  • El "buen diseño de la web" requiere que se envíen acciones no inocentes a través de POST. Esta es una acción no inocente.
  • Es más fácil desarrollar y depurar esta aplicación cuando los parámetros de la petición están presentes en la URL.
  • El API no está destinado a un uso generalizado.
  • Parece que hacer una petición POST sin cuerpo llevará un poco más de trabajo, por ejemplo, un Content-Length: 0 el encabezamiento debe ser añadido explícitamente.
  • También me parece que un POST sin cuerpo va un poco en contra de las expectativas de la mayoría de los desarrolladores y marcos HTTP.

¿Hay más trampas o ventajas en el envío de parámetros en una solicitud POST a través de la consulta de la URL en lugar del cuerpo de la solicitud?

Editar: La razón por la que se está considerando esto es que las operaciones no son identarias y tienen efectos secundarios distintos de la recuperación. Véase la especificación HTTP :

En particular, la convención ha sido estableció que el GET y HEAD los métodos NO DEBEN tener el importancia de tomar una acción otra que la recuperación. Estos métodos deberían ser considerado "seguro". Esto permite al usuario agentes para representar otros métodos, como POST, PUT y DELETE, en un de manera especial, para que el usuario se haga consciente del hecho de que un posible se solicita una acción insegura.

...

Los métodos también pueden tener la propiedad de "idempotencia" en eso (aparte de error o problemas de caducidad) el efectos secundarios de N > 0 idénticos es la misma que la de un solo solicitud. Los métodos GET, HEAD, PUT y BORRAR compartir esta propiedad. También, los métodos OPCIONES y RASTREO DEBEN NO tienen efectos secundarios, y también lo son intrínsecamente idependiente.

97voto

Don McCaughey Puntos 4433

Si tu acción no es idévola, entonces tú DEBE use POST . Si no lo haces, te estás buscando problemas en el futuro. GET , PUT y DELETE Los métodos son requerido para ser identor. Imagina lo que pasaría en tu aplicación si el cliente estuviera buscando todo lo posible GET solicitud de su servicio si esto causaría efectos secundarios visibles para el cliente, entonces algo está mal.

Estoy de acuerdo en que enviar un POST con una cadena de consulta pero sin un cuerpo parece extraño, pero creo que puede ser apropiado en algunas situaciones.

Piense en la parte de la consulta de una URL como un comando al recurso para limitar el alcance de la solicitud actual. Típicamente, las cadenas de consulta se usan para ordenar o filtrar una GET solicitud (como ?page=1&sort=title ) pero supongo que tiene sentido en un POST para limitar también el alcance (tal vez como ?action=delete&id=5 ).

44voto

Powerlord Puntos 43989

¿Quieres razones? Aquí hay una:

No se puede usar un formulario web para enviar una solicitud a una página que usa una mezcla de GET y POST. Si se establece el método del formulario en GET, todos los parámetros están en la cadena de consulta. Si se establece el método del formulario en POST, todos los parámetros están en el cuerpo de la solicitud.

Fuente: Estándar HTML 4.01, sección 17.13 Presentación de formularios

41voto

Tim Lovell-Smith Puntos 2635

Hasta ahora todo el mundo tiene razón, sigue con el POST para las solicitudes no impopulares.

¿Qué hay de mezclar las consultas de URI y el contenido? Es HTTP válido, así que, ¿por qué no?

La especificación HTTP (1.1) no establece que los parámetros y el contenido de la consulta se excluyan mutuamente en una aplicación de servidor http que acepte solicitudes POST, o solicitudes PUT, por lo que es libre de aceptar ambas. Y por supuesto si escribes el servidor no hay nada que te impida aceptar ambos (excepto quizás un marco de trabajo inflexible). El servidor elige cómo interpretar las cadenas de consulta como quiera. Y puede interpretarlas de forma diferente basándose en cabeceras como Content-Type también, si así lo desea.

Ahora bien, si un navegador de Internet. es la principal forma en que la gente accede a su aplicación web, y aplicación/x-www-form-urlencoded es el tipo de contenido que están publicando, entonces usted debería seguir las reglas para ese tipo de contenido, que son mucho más específicas, y francamente, inusuales: en este caso debes interpretar el Uri como un conjunto de parámetros, y no como una ubicación de recursos. (Este es el punto de utilidad que Powerlord planteó, que puede ser difícil usar formularios web para enviar contenido a su servidor, sólo que explicado de manera diferente).

Nota: ¿para qué son las cadenas de consulta originalmente? La RFC 3986 define las cadenas de consulta http como una parte uri que funciona como una forma no jerárquica de localizar un recurso.

En caso de que los lectores se pregunten qué es una arquitectura RESTful aceptable, la arquitectura RESTful no prescribe que los esquemas de URI funcionen de una manera muy específica, excepto para satisfacer propiedades como la caché. La arquitectura RESTful está más preocupada por los recursos en sí mismos, su comportamiento, capacidades y representaciones, y si se satisface la idempotencia. La arquitectura RESTful puede estar menos preocupada por cómo los recursos son localizado en .

(Otra nota: a veces se abusa de los parámetros de consulta para fines distintos de la localización de recursos o la codificación del contenido. ¿Alguna vez has visto un parámetro de consulta como PUT=true o POST=true? Estos son soluciones provisionales para los hosts de aplicaciones que no permiten enviar solicitudes PUT y POST de forma nativa, sino que sólo permiten GET.)

6voto

jro Puntos 5120

Desde un punto de vista programático, para el cliente es empaquetar los parámetros y añadirlos a la url y realizar un POST vs. un GET. En el lado del servidor, está evaluando los parámetros de entrada de la cadena de consulta en lugar de los bytes enviados. Básicamente, es un lavado.

Donde podría haber ventajas/desventajas podría ser en la forma en que las plataformas de clientes específicos trabajan con las rutinas POST y GET en su pila de red, así como en la forma en que el servidor web trata esas solicitudes. Dependiendo de su implementación, un enfoque puede ser más eficiente que el otro. Saber eso guiaría su decisión aquí.

Sin embargo, desde la perspectiva de un programador, prefiero permitir un POST con todos los parámetros del cuerpo, o un GET con todos los parámetros en la url, e ignorar explícitamente los parámetros de la url con cualquier petición POST. Evita la confusión.

2voto

saille Puntos 3585

El DESCANSO tienen algunos principios rectores que podemos usar para estandarizar la forma en que usamos los verbos HTTP. Esto es útil cuando se construyen API's RESTful como se está haciendo.

En pocas palabras: GET debe ser de sólo lectura, es decir, no tiene efecto en el estado del servidor. POST se utiliza para crear un recurso en el servidor. PUT se utiliza para actualizar o crear un recurso. DELETE se utiliza para eliminar un recurso.

En otras palabras, si su acción de la API cambia el estado del servidor, REST nos aconseja usar POST/PUT/DELETE, pero no GET.

Los agentes de usuario normalmente entienden que hacer múltiples POSTs es malo y lo advertirán, porque la intención del POST es alterar el estado del servidor (por ejemplo, pagar por las mercancías en la caja), ¡y probablemente no quieras hacer eso dos veces!

Compara con un GET que puedes hacer un "often as you like" (idempotente).

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X