Re: [Resteasy-developers] RESTful web services in Java EE with RESTeasy (JAX-RS)

[Stef E. <st...@ep...>]

On Thu, Jun 26, 2008 at 08:52:21AM -0400, Bill Burke wrote:
> I don't think there's a nice way to do this.  We played around with the 
> idea of having a @Location annotation with embeddable EL:
> 
> @Location("/blah/foo/${foo.id}")
> MyBean post() {...}
> 
> But I just don't think it fits for every scenario because the response 
> codes may be different.  How do you think we could change this?

One way to do it would be to have a @Context Response injected on which
we could set whatever info we want prior to returning MyBean. This way
we can set both the HTTP code and the additional headers if needed.

> >For some reasons, the HTTP header returned by using
> >Response.status(x).location("foo") is lowercased ("location:" instead of
> >"Location:"). Even though this is perfectly acceptable in terms of the
> >HTTP standard, it is uncommon I think.
> 
> This is legal too "lOcAtIoN"  so, i just convert everything to lowercase 
> to make sure there's no errors in header processing anywhere just to be 
> safe.

I know this is legal, I'm just saying it is unusual, I would have made
all the header handling case-insensitive while actually keeping the case
set when the header was added, but it does not really matter much :)

> >We've had a design question regarding encodings, for instance all our
> >methods/resources produce "application/xml" on success, but "text/plain"
> >on failure. We've had to declare that they can produce both with
> >@ProduceMime( { "application/xml", "text/plain" }) and then set the mime
> >type and encoding ourselves in each Response built and returned. Maybe
> >this could be made easier?

I think this point was skipped, maybe on purpose, but maybe not :)
I don't have any suggestion for this one I'm afraid.

> I'm not sure, i have mixed feelings about WADL.  How would you go about 
> implementing a client in a different language?  Well, just use their 
> HTTP library.  IMO, the code isn't much different than sending messaging 
> with any other messaging layer.  Its actually less verbose than JMS to 
> do straight HTTP.

Well, writing client-side remote APIs seems to me like a thing of the
past. When I want to talk to a web service, I expect that they either
give me the client-side library, or even better a web service descriptor
that I can use to automatically generate the client-side library in any
language/framework. RESTful, HTTP, XML are all cross-platform standards,
why should I expect to write manually a client-side library in .NET to
be able to talk to my Java RESTful web service?

I suspect I can already auto-generate XML object representations in
several languages using the JAXB-generated XSD, but having to write
manually the whole client-side binding for each and every resource
operation seems like a really boring task I would have hoped passé.

Even though I have some doubts about WADL's ability to represent
exceptions if only because they are not part of the server API (they are
hidden in the Response object, even if declared in the "throws" clause,
because they will then be converted into a Response object later on).
SOAP does declare exceptions though, and it's handy.

> Well, subscribe to our dev list and post the changes you want to JAXB!

To be honest the changes I want to JAXB I haven't had time to implement
them, and I'm not sure if my tight work deadlines will allow me to, but
really I need to at least get a hand to the guys working on the next
JAXB version if there is one under way to see if all the problems we
have with it can/should be solved.

Thanks again for your feedback :)
-- 
Stéphane Epardaud