I agree with the gist – that there are pros and cons to each approach – but I disagree with the conclusion. Towards the end of the blog, Jon writes;
It’s a great idea to push the abstraction of the core primitives above the level of SELECT/CUT/PASTE. But there’s little to be gained by pretending that a table of contents is a pivot table.
If you’ve already deployed a network interface which is capable of accessing and manipulating pivot tables, then there is an enormous amount to be gained from being able to reuse this interface to access and manipulate table of contents, table of figures, or even dining room tables. Deploying new interfaces on the Internet is extremely difficult, expensive, and time consuming. The SELECT/CUT/PASTE analogy, while illustrative, doesn’t reflect the nuances of a network interface, which must work between multiple trust domains, not within just one.
WRT “ANALYZE” and “IMPROVE”, both of those “actions” can be accomplished without introducing new methods on the interface. For example, “ANALYZE” is a safe action, so could be handled as piping your content through an intermediary via a GET invocation, where it “analyzed” the content and returned the results (perhaps using annotation). “IMPROVE”, as I understand it, could be implemented similarly, but using WebDAV‘s COPY method, or maybe just PUT or POST; it depends how it’s used. Either way though, the intermediary would do the “improving”.
P.S. I like to use the “drag and drop” desktop metaphor as a comparison to REST’s uniform interface; GET as “double-click” (except for application-invocation, which isn’t technically part of drag-and-drop), POST as drag-and-drop, PUT as “file->save”, and DELETE as delete. This analogy breaks down with the drag-to-trash-can action, but it holds for the most part because drag-and-drop was designed as an interface for “all desktop objects” which is pretty similar to “all resources”.