- From: Asbjørn Ulsberg <asbjorn@ulsberg.no>
- Date: Sun, 13 Mar 2016 22:27:46 +0100
- To: Karol Szczepański <karol.szczepanski@gmail.com>
- Cc: public-hydra@w3.org, Tomasz Pluskiewicz <tomasz@t-code.pl>
On 13. mar. 2016, at 19.09, Karol Szczepański <karol.szczepanski@gmail.com> wrote:
> PUT /blog/{id} - update the blog with a published state
It’s nitpicking, but you can’t really update anything with PUT. You can only replace the entire resource. If you want to change the value of a single property and leave all other properties of the resource untouched, you’d need to use PATCH.
> It would be also more approriate (in my opinion) to allow client to put existing blog directly to either of the states with PUT - if the client is instructed on how to build a valid Uri.
> HTTP spec allows PUT to create a resource if the Uri is known.
Besides having to know the URI before doing PUT, functionally PUT and POST are equivalent here, I’d say. Why does PUT make more sense than POST, in your opinion?
> As an ultimate solution I'd ... use the hypermedia controls like next/prev to transition between resource states.:
> 1. POST /blog - create a new blog with a system's default state (draft) -> Location: /blog/{id}
> 2. GET /blog/{id} - get's the blog post with additional link hydra:next pointing to an operation which can be used to move the blog post to another state
> 3. POST/PUT {link from the hydra:next} - move the resource to another state
That’s an interesting idea, although I’ll repeat that PATCH probably works better here unless you make the state itself a resource you can POST or PUT to, such as:
PUT /blog/{id}/state
--
Asbjørn Ulsberg -=|=- asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»
Received on Sunday, 13 March 2016 21:28:18 UTC