Dado que la solicitud POST en un patrón POST/Redirigir/GET (PRG) devuelve un código de estado de redireccionamiento (303 See Other) en caso de éxito, ¿es posible informar el cliente del sabor específico de éxito que van a disfrutar (por ejemplo, OK, Creado, Aceptado, etc.), así como cualquier encabezado apropiado (por ejemplo, Location para un 201 Created, que podría entrar en conflicto con el de la redirección)?POST/Redirigir/OBTENER (PRG) versus códigos de respuesta 2xx significativos
¿Sería apropiado, por ejemplo, hacer que el GET redirigido responda con el código de respuesta adecuado & encabezados que se esperarían de la respuesta POST?
La especificación HTTP 1.1 dice:
Este método [303] existe principalmente para permitir la salida de una secuencia de comandos activado-POST para redirigir el agente de usuario a un recurso seleccionado.
Pero no ofrece ninguna información sobre la pérdida del código de estado y los encabezados más habituales.
Edición - Un ejemplo:
Un cliente envía una solicitud POST a /orders que crea un nuevo recurso en /orders/1.
Si el servidor envía un estado 201 Created con location: /orders/1, un cliente automatizado estará contento porque sabe que el recurso fue creado, y sabe dónde está, pero un humano que use un navegador web no estará contento, porque obtienen el página /orders nuevamente, y si lo actualizan, enviarán otra orden, lo que es poco probable que sea lo que quieren.
Si el servidor envía un estado 303 See Other con location: /orders/1 el humano será llevado a su orden, informado de su existencia y estado y no correrá el riesgo de repetirlo por accidente. Sin embargo, al cliente automático no se le informará explícitamente sobre la creación del recurso, deberá inferir la creación basada en el encabezado location. Además, si el 303 redirige a otro lugar (por ejemplo, /users/someusername/orders), el humano puede estar bien acomodado, pero el cliente automatizado queda drásticamente desinformado.
Mi sugerencia fue enviar 201 Created como la respuesta a la solicitud redirecciona en el nuevo recurso, pero cuanto más lo pienso, menos me gusta (podría ser difícil de garantizar que sólo el creador recibe el 201 y no debería aparecer que la solicitud GET creó el recurso).
¿Cuál es la respuesta óptima en esta situación?
¿Puedes dar un ejemplo de lo que pensabas? – Gumbo
He editado la pregunta para dar un ejemplo. Gracias. –
Para que quede claro: ¿Ya se ha asegurado de que un usuario humano esté bien informado sobre lo que acaba de suceder, y ahora está tratando de hacer lo mismo con uno automatizado? – sdleihssirhc