Según la especificación HTTP/1.1
El método POST
se utiliza para solicitar que el servidor de origen acepte la entidad incluida en la solicitud como un nuevo subordinado del recurso identificado por la Request-URI
en la Request-Line
.
En otras palabras, POST
se utiliza para crear.
El método PUT
solicita que la entidad adjunta sea almacenada bajo la Request-URI
suministrada. Si la "URL de solicitud" se refiere a un recurso ya existente, la entidad adjunta debería considerarse como una versión modificada de la que reside en el servidor de origen. Si el Request-URI
no apunta a un recurso existente, y ese URI es capaz de ser definido como un nuevo recurso por el agente de usuario solicitante, el servidor de origen puede crear el recurso con ese URI;
Es decir, PUT
se utiliza para crear o actualizar.
Entonces, ¿cuál debe usarse para crear un recurso? ¿O hay que soportar ambos?
En general:
Tanto PUT como POST pueden utilizarse para crear.
Tienes que preguntarte "¿a qué estás realizando la acción?" para distinguir qué deberías usar. Supongamos que estás diseñando una API para hacer preguntas. Si quieres usar POST, entonces lo harías a una lista de preguntas. Si quiere usar PUT, lo haría a una pregunta en particular.
Se pueden usar ambos, así que cuál debo usar en mi diseño RESTful:
No es necesario que admita tanto PUT como POST.
El uso de ambos depende de ti. Pero recuerde usar el correcto dependiendo del objeto al que haga referencia en la solicitud.
Algunas consideraciones:
Un ejemplo:
Escribí lo siguiente como parte de otra respuesta en SO con respecto a esto:
POST:
Se utiliza para modificar y actualizar un recurso
POST /questions/
HTTP/1.1 Host: www.example.com/ Tenga en cuenta que lo siguiente es un error:
POST /questions/
HTTP/1.1 Host: www.example.com/ Si la URL aún no está creada, usted no debería usar POST para crearla mientras se especifica el nombre. Esto debería resultar en un 'recurso no encontrado' error porque
<new_question>
no existe todavía. Debe PUTAR el recurso<new_question>
. en el servidor.Sin embargo, podría hacer algo como esto para crear un recurso usando POST:
POST /preguntas HTTP/1.1 Host: www.example.com/
Tenga en cuenta que en este caso el recurso no se especifica el nombre, los nuevos objetos La ruta de la URL le será devuelta.
PUT:
Se utiliza para crear un recurso, o sobrescribirlo. Mientras se especifica la recursos la nueva URL.
Para un nuevo recurso:
PUT /questions/
HTTP/1.1 Host: www.example.com/ Para sobrescribir un recurso existente:
PUT /questions/
HTTP/1.1 Host: www.example.com/
Utilice POST para crear, y PUT para actualizar. Así es como lo hace Ruby on Rails, de todos modos.
PUT /items/1 #=> update
POST /items #=> create
REST es un concepto de muy alto nivel. De hecho, ¡ni siquiera menciona HTTP!
Si tienes alguna duda sobre cómo implementar REST en HTTP, siempre puedes echar un vistazo a la especificación Atom Publication Protocol (AtomPub). AtomPub es un estándar para escribir servicios web RESTful con HTTP que fue desarrollado por muchas luminarias de HTTP y REST, con algunas aportaciones de Roy Fielding, el inventor de REST y (co)inventor del propio HTTP.
De hecho, es posible que puedas utilizar AtomPub directamente. Aunque surgió de la comunidad de blogueros, no se limita en absoluto a los blogs: es un protocolo genérico para interactuar de forma REST con colecciones arbitrarias (anidadas) de recursos arbitrarios a través de HTTP. Si puedes representar tu aplicación como una colección anidada de recursos, entonces puedes usar AtomPub y no preocuparte de si usar PUT o POST, qué códigos de estado HTTP devolver y todos esos detalles.
Esto es lo que AtomPub tiene que decir sobre la creación de recursos (sección 9.2):
Para añadir miembros a una colección, los clientes envían peticiones POST al URI de la colección.