Re: Extend describing operations

Hi,

Am 13.03.2016 um 22:27 schrieb Asbjørn Ulsberg:
> 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.

According to a tweet by fielding [1], I wouldn't call this nitpicking.
The main problem are concurrent updates, as I see it.

[1] https://twitter.com/fielding/status/275471320685367296


> 
>> 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
> 

What also makes this approach for partial updates very recommendable is
the fact that it is supported by the http rfc:

"Partial content updates are possible by
targeting a separately identified resource with state that overlaps a
portion of the larger resource"

[2] http://tools.ietf.org/html/rfc7231#section-4.3.4

It also allows to restrict the updatable properties.

In comparison, building and processing a patch file is not a trivial
task, neither for the client nor the server. E.g. json-patch is
incredibly powerful.


Best regards,
Dietrich

Received on Sunday, 3 April 2016 14:15:15 UTC