In CouchDB, to create a new document you send:
PUT /albums/70b50bfa0a4b3aed1f8aff9e92dc16a0
Isn't PUT used to update data and not creating it?
In CouchDB, to create a new document you send:
PUT /albums/70b50bfa0a4b3aed1f8aff9e92dc16a0
Isn't PUT used to update data and not creating it?
It's used for both. Quoth the RFC:
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.
PUT
is indeed used for updating content, but if you already have an id, you're updating. In REST generally, you'd POST
to /albums
(or whatever) to create a new record with an as-yet unknown id. Since you have an id, you're updating the empty document with that id to the content you're providing.
PUT is to create a new or replace entirely an existing resource when you know the existing URI or what the new URI will be. POST is for updating parts of an existing resource, or for creating a new resource when the server has to assign the new URI. It's that simple. Both PUT and POST are used for creates and updates, it's not about if you're creating or updating, it's about whether you already know the URI or you need the server to assign it for you.
The key term for PUT for me is always idempotent. While for POST you are always "adding another" item to the systems-state, with PUT the action is the same even if multiple times performed (because you are adressing an item).
Example:
doing 100-times POST /albums = you would end up with 100 different albums (but with same content)
doing 100-times PUT /albums/123 = you would end up with one single album with id 123 (with the content)