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

[Bill B. <bb...@re...>]

Stef Epardaud wrote:
> 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.
> 

You don't have to put "text/plain" in your @ProduceMime.  It is only for 
matching against ACCEPT headers.  You can override the content type 
within Response

>> 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?
> 

IMO, a client-side library distributed by the server is a no-no.  Its ok 
with a handful of clients, but what happens when you have 100, 1000, 
10000 clients?  Its starts to become a real pain to update and 
distribute stubs. The lack of client stubs is one of the many reasons I 
liked the REST approach to begin with.


> 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é.
> 

It just seemed to me that the amount of code I was saving using the 
Resteasy client-proxy framework wasn't much compared to straight Apache 
HttpClient code.

I think if you think of REST as a messaging pattern rather than an RPC 
one, you start to feel differently about WADL and stub generation. 
There are so many things you can do in a pure messaging paradigm that 
you can't do in an RPC based system.  For example, different clients may 
want to handle different response codes, mime-types, and response 
headers differently.


> 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.
> 

On JAXB, I meant, describe the changes you want in email, and we'll do 
the work!

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com