A few comments. First, "few verbs" is not a key idea of REST.
It is a very strong guideline IMO :)
Second, putting the verb in the URL is a Really Bad Idea™.
I would go further down the path and say - this really isn't allowed at all.
There's much more I could say about what you've written in the wiki, but let me cut it short and simply ask this: what are the goals of having CXF "support REST"? Who or what does it benefit? What kinds of systems do you envision making use of that support? Considering these questions and their possible answers within the constraints of the REST architectural style [1] is the only way to get this truly right, IMO.
I can only talk for the use case that I have direct access to - I have a server that maintains a memory model of a set of entities that can be serialized to an XML vocabulary. These set of entities can be influenced by a client application, local to the client's address space. The set of entities may be large, so the client loads entities on-demand. If changes are made on the client side, the changes are collated using an XML change language and are submitted to the server - the server applies the changes to the definitive set of entities that it maintains. So - the set of entities is reflected as a Resource, with a URL (in fact the entities themselves are also resources, so to load a resource, the client issues a GET). When the client issues the change request, it is couched as a POST accompanied by the change language document. The implementation on the server side receives a 'post' method call with an XML document as the argument - there is no type mapping, unmarshalling or any of that, it is pretty much an application protocol approach. The content of the POST expresses an update to the state of the resource. Summary: cxf supporting REST means that there is a way to program servants to react to HTTP as an application protocol, rather than as a layered protocol. cheers --oh
