POST

El método POST solicita que el recurso de destino procese la representación incluida en la solicitud de acuerdo con la semántica específica del propio recurso. Por ejemplo, POST se utiliza para las siguientes funciones (entre otras):

• Proporcionar un bloque de datos, como los campos introducidos en un formulario HTML, a un proceso de tratamiento de datos;
• Publicar un mensaje en un tablón de anuncios, grupo de noticias, lista de correo, blog o grupo similar de artículos;
• Crear un nuevo recurso que aún no ha sido identificado por el servidor de origen; y
• Añadir datos a la(s) representación(es) existente(s) de un recurso.

Un servidor de origen indica la semántica de la respuesta eligiendo un código de estado apropiado en función del resultado del procesamiento de la solicitud POST; casi todos los códigos de estado definidos por esta especificación podrían recibirse en una respuesta a POST (las excepciones son 206 (Contenido parcial), 304 (No modificado) y 416 (Rango no satisfactorio)).

Si uno o más recursos han sido creados en el servidor de origen como resultado de procesar con éxito una petición POST, el servidor de origen DEBERÍA enviar una respuesta 201 (Created) que contenga un campo de cabecera Location que proporcione un identificador para el recurso primario creado (Sección 7.1.2) y una representación de que el recurso primario ha sido creado.1.2) y una representación que describe el estado de la petición mientras hace referencia al nuevo recurso(s).

Las respuestas a peticiones POST sólo son almacenables en caché cuando incluyen información explícita de frescura (ver Sección 4.2.1 de [RFC7234]). Sin embargo, el almacenamiento en caché de POST no está ampliamente implementado. Para los casos en los que un servidor de origen desea que el cliente sea capaz de almacenar en caché el resultado de un POST de forma que pueda ser reutilizado por un GET posterior, el servidor de origen PODRÍA enviar una respuesta 200 (OK) que contenga el resultado y un campo de cabecera Content-Location que tenga el mismo valor que el URI de petición efectiva del POST (Sección 3.).1.4.2).

Si el resultado de procesar un POST fuera equivalente a una representación de un recurso existente, un servidor de origen PODRÍA redirigir al agente de usuario a ese recurso enviando una respuesta 303 (See Other) con el identificador del recurso existente en el campo Location. Esto tiene las ventajas de proporcionar al agente de usuario un identificador de recurso y transferir la representación a través de un método más susceptible de almacenamiento en caché compartido, aunque a costa de una petición adicional si el agente de usuario no tiene ya la representación almacenada en caché.

Servidor de origen.