> Ouchy. Basically, it looks like you're taking a very narrow view of REST and conflating lots of it with historical RPC-ish thinking.

My view of REST is narrow only in the sense that I've actually read the document where the term originated, which gives a rather precise (in places mathematically precise) definition of the term. If this level of rigor interests you then you can find this document at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch.... There only thing that is 'historical' about RPC is the thousands of real-world applications implemented in this style in every conceivable area of distributed computing over the last 3 or 4 decades. Whole programming languages both academic (Newsqueak) and industrial (Erlang) are premised on the notion of distributed message passing and you will be hard pressed to find any nontrivial distributed system that doesn't require the ability to invoke a verb over the network (including HTTP). From Fielding's dissertation:

'The primary distinction between network-based architectures and software architectures in general is that communication between components is restricted to message passing [6], or the equivalent of message passing if a more efficient mechanism can be selected at run-time based on the location of components [128].'

HTTP itself is a form of RPC, with distinct named methods and a way of passing arguments and retrieving results. Hard-line REST advocates fall into one of four categories:

1) They believe that HTTP is a wonderful RPC protocol for doing CRUD on entities that can be roughly called 'documents', but would never dream of trying to torture some dramatically different domain into this model. When they are writing services that are document processing services they write them in a 'RESTful' style, and they otherwise never do.
2) They believe that all network transactions can be sensibly accomplished with a model that has only GET, PUT, POST, HEAD and DELETE, and that uses them as originally intended.
3) They believe that any software system that can't be accomplished as with (2) above isn't worth writing. (Web 2.0 with Rails anyone?)
4) They don't know what REST means.

If #2 describes someone then he or she is inexperienced or stupid or both, if #3 describes someone then he or she is a fashion-conscious Web 2.0 asshole who will only ever receive money that came from a venture capitalist and never money that came from a customer. Ever. And if #4 describes someone then he or she really ought to read the literature before posting flippant drive-by commentary to Hacker News in what can only be some lame attempt at karma-whoring on the fashionability of the word 'REST'.

> Please name one that's actually needed.

Before replying to this I need to make it explicitly clear that I can only reply to what I think you're actually saying, so excuse (and correct) me if I reply to something that you didn't actually say. It sounds to me like you're proposing that GET, PUT, POST, HEAD, and DELETE are the only verbs that anyone should ever be interested in invoking over a network. Now there is a sense in which they might be sufficient for most transactions since you can attach an arbitrary payload to a POST and receive and arbitrary reply, but I think almost anyone would agree that this falls under the point made in my original post about the fact that people actually just want lightweight RPC when they talk about REST.

For the sake of argument I'm happy to propose something that people might like to do with a web-service that doesn't fit a document CRUD model: play chess. Now while you may be able to GET a description of the current board with some resource identifier like /chess/game/1234/board, you will no doubt also want to MOVE and maybe even CONCEDE, and the moment that you've started POSTing to URLs that look like /chess/game/1234/move or /move/new you're right back to POSTing to a URL with another method name in it, i.e. lightweight RPC over HTTP and it's not REST anymore. The chess example is arguably contrived (and arguably not) but it doesn't take much imagination to start picturing web services for the remote compilation of code, or the provisioning of mobile devices, or calibration of remote underwater sensors. Just because a bunch of people have decided that social-networking is the most demanding application that we as developers should ever contemplate doesn't mean that the ability to do distributed message passing and procedure call is obsolete. Plenty of people are making plenty of money doing just that.