[deletia]
What you say about using HTTP as an app protocol -- as it was
designed to be used, frankly -- is definitely a requirement.
+1 - this is step 1
However, there's more as well -- REST also requires supporting
navigation of application state via hyperlinks, which means that
CXF has to enable and perhaps help the server-side application to
generate the URLs required to identify new resources that it
creates and tie servants/implementations to them.
+1
Applications have to play their part, too, by following the
semantics of HTTP, such as ensuring that GETs are idempotent, and
ensuring that the URLs it produces for its resources and state
aren't just always temporary or transient.
+1 - wow I seem to be very agreeable today.
It's the enforcement of the idempotency and the persistent of URLs
that are the
pieces that most development might miss out on. If there was some way
to automate
the assurance of these semantic elements, then you could say that
something was
truly REST-supportive. Without a formal definition of state
representation in the
programming language (or even an informal one :) then this is always
going to be
delivered on a case-by-case basis and is prone to error.
I guess for cxf that the priority is getting the 'application
protocol' support
in place to deliver payload to a 'servant' with information about the
HTTP
context. This is what was available in Celtix 1.0 and is in use :)
cheers
--oh
