Re: Extend describing operations

April 7 2016 9:07 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote: 
>> Yes of course, but doesn't approach reduce the API to a CRUD. Want to
>> publish the BlogPost? Change the status property and PUT/PATCH the
>> resource or PUT the status resource.
> 
> You can obviously also define a different message and post it to some URL to get it processed by
> the server. That's more work without a clear benefit though IMO.
> 

I'm thinking that such API would be easier to reason about and shape dynamically.

For example how would I restrict changing the state, say, because the current user doesn't have the right or it's not possible to change from state A to state B? I'm guessing a very rich restriction description must be used to instruct the client what it can do with the resource. With these interactions modelled as operations it's simply not including it in the representation/documentation.

A separate /post/status resource does have more power in that regard but I've seen people complaining about such resource design. 

-----

I've just now thought about actual interaction with user interfaces. CRUD where changing a property to publish etc. would be a smell from the UX perspective. If the act of publishing is an established business operation it should be also modelled accordingly at the API level so that the API/UI drives human interaction.

This may be the greatest benefit here.

Received on Friday, 8 April 2016 08:06:54 UTC