REST was never about CRUD
This is an oft revisited topic, and it might be worthwhile to cite a few paragraphs from Dr Fielding in order to support and expand upon the submitted article.<p>&quot;Search my dissertation and you won’t find any mention of CRUD or POST.&quot; [0]<p>&gt; For example, some APIs may need to support actions such as submit, approve, and decline. With our somewhat limited action verbs in HTTP, how can we add this to our API?<p>By representing the difference in states. Or otherwise. The communication medium is not the API. (&quot;A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. &quot; [1])<p>&gt; POST &#x2F;articles&#x2F;{articleId}&#x2F;publish , POST &#x2F;articles&#x2F;{articleId}&#x2F;submit , ... etc.<p>A few years ago I was zealously advocating against representing actions in URIs, and using a generic &#x2F;actions [sub]resource, but this actually makes it simpler to represent the available actions to the client. And sure, this can be thought of as REST via the code-on-demand part of the architecture. The server points to a script (it doesn&#x27;t have to be JS, but the media type must be defined in the REST API), that can understand the available actions from the state representation, and construct the necessary representations for the desired actions. (So in a HTTP API, the JS interprets the JSON and knows how to put together POST requests to modify the resources, without the actions having been reified and URI-fied in the JSON.)<p>&gt; The workflow our API supports is more explicit, [...]<p>Sure, that&#x27;s pragmatic, but after much gnashing of teeth and scratching of heads, REST is about presenting options to the client by offering various media types (content-types), and letting the client request the best representation, and not really about a fixed ACL neither about fixed flow.<p>From [1] again: &quot;A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and&#x2F;or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]&quot;<p>[0] <a href="https:&#x2F;&#x2F;roy.gbiv.com&#x2F;untangled&#x2F;2009&#x2F;it-is-okay-to-use-post" rel="nofollow">https:&#x2F;&#x2F;roy.gbiv.com&#x2F;untangled&#x2F;2009&#x2F;it-is-okay-to-use-post</a><p>[1] <a href="https:&#x2F;&#x2F;roy.gbiv.com&#x2F;untangled&#x2F;2008&#x2F;rest-apis-must-be-hypertext-driven" rel="nofollow">https:&#x2F;&#x2F;roy.gbiv.com&#x2F;untangled&#x2F;2008&#x2F;rest-apis-must-be-hypert...</a>