DEV Community

loading...

Discussion on: Explain "Store" resource archetype in REST like I'm five

Collapse
nestedsoftware profile image
Nested Software

I think of this in terms of the PUT or PATCH method. When you use PUT, you provide some data and you say "please store this data at the location (uri) I've specified". For example: PUT /books/3 will take the information about a particular book from the body of a request and store that information in /books/3. You can then retrieve that information with GET /books/3. It's part of the contract for PUT that you can use GET in this way afterward.

How does this apply to the "store" resource archetype? The main idea is that the client tells the server what uri to use for a given resource. As a counter-example, with POST, you'd do something like POST /books. This would take the information about a book from the body of the request and create a new book resource. However, the client has no control over how to retrieve that book - so this would be the "collection" archetype.

Note: The difference between PUT and PATCH is that PUT requires all of the data for a book (it will replace the book) whereas PATCH will leave any existing data alone. For example, with PATCH you can update just the title of a book, leaving out the other fields. If you did that with PUT, any other fields would be removed. In both cases, if the record does not exist at the specified uri, it will be created, and if it does exist, it will be either replaced (PUT) or updated (PATCH).