> -----Original Message----- > From: Hurley, Oisin > Sent: 2006?9?8? 20:40 > To: [email protected] > Subject: Re: REST support proposal for review > > > [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 :)
Hi Oisin, would you mind elaborating into more details on what will be involved to get the "application protocol" support in place? Would the JAX-WS provider approach I described early satisfy the requirement? Also regarding your point of "with information about the HTTP context", I will make the URI path info available to provider, I am not sure if there is anything else needed to proceed REST. For example, Sergey raise a point early that HTTP GET is actually a hint to perform a get operation. If this is the case, we need to make HTTP method available to JAX-WS provider as well. > > cheers > --oh >
