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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

CCing dev list, comments inlined.

Stef Epardaud wrote:
> On Wed, Jun 25, 2008 at 11:58:58PM +0200, Peter Hilton wrote:
>>    Great article!!!  Thanks for showcasing RESTEasy!
> 
> Many thanks to you for RESTeasy :)
> 
>>    * Can you provide some feedback on the bugs you had to fix in RESTEasy?  I
>>    could get them fixed really fast.
> 
> To be honest I've stuck to the svn revision r104 ever since we got
> everything we wanted to work, you know how production software
> constraints are.
> 
> Mostly I've fixed some exception handling bugs, for instance exceptions
> which were not correctly unwrapped to WebException.
> 
> Here is the full list of changes, but I'm sure most have been fixed:
> 
> MessageBodyParameterExtractor: 
>  - Throw HTTP_UNSUPPORTED_TYPE if request has no mediaType
>  - Throw HTTP_UNSUPPORTED_TYPE if factory.createMessageBodyReader
>    returned null

Ok, I'll double check that we have a test for this now.

> ResourceMethod:
>  - Unwrap Exceptions in every catch (using Throwable.getCause()) in
>    order to find possible WebApplicationException with a Response.
> 

Good one.

> That's it!
> So it was really minimal and I'm sure they have been fixed since :)
> 
>>    * JAX-RS has ExceptionMappers  these are available in RESTEasy beta 5.
>>    public interface ExceptionMapper<E>
>>    {
>>      /**
>>       * Map an exception to a {@link javax.ws.rs.core.Response}.
>>       *
>>       * @param exception the exception to map to a response
>>       * @return a response mapped from the supplied exception
>>       */
>>      Response toResponse(E exception);
>>    }
> 
> That seems like a nice feature. While building the application, I've
> wondered about the correct way to declare my functions:
> 
> @GET
> Order getOrder();
> 
> or
> 
> @GET
> Response getOrder();
> 
> Basically we decided to make them all return Response, but this is not
> as much for exceptions as for normal returns. For instance on many POST
> and PUT we want to return a "Location:" HTTP header, and sometimes we
> return HTTP_CREATED or HTTP_OK, and I haven't found a way to make this
> work with just returning an instance.
> 
> From a purely architectural point of view this is sad because the API
> interface doesn't reflect what is being returned, but I don't really
> know how an alternative would look like.
> 

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?

>>    * Any suggestions to make JAX-RS or RESTEasy better?
> 
> I've had an issue with @Context UriInfo, which was never injected
> properly when declared as a field, so I had to make them parameters all
> the time, which pollutes the API interface, but I think the
> documentation said fields were supported so I'm sure this has been fixed
> since.
> 

Its supported now.

> Also, we wanted to provide custom responses for each unsupported
> operations, like "POST is not supported for resource /foo", but because
> I haven't found a way to get access to the HTTP method name, I've had to
> write one resource handler for each unsupported method. It would be nice
> to provide either a way to customize any response generated by the JAX-RS
> framework (media type not supported, method not supported, resource does
> not exist).
> 

This is probably a good idea in general and should done in conjunction 
with any internationalization effort.

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

> 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?
> 
> Last but probably the most important question: is there any planned
> support for generation of WADL or any cross-language RESTful API
> descriptor (if anything else than WADL exists) so that we could generate
> it directly from the server implementation? That would be very nice
> because I'm not really sure how one would go about implementing a client
> in a different language. Maybe it's just me being used to SOAP or CORBA
> ;)
> 

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.

> I've just had a look at all the new features you've added since I
> stopped upgrading RESTeasy, they all look great, you've done an amazing
> job, many thanks for this quality software.
> 
> To be honest the most gripes and problems I've had while using RESTeasy
> were with JAXB. While it has some really nice features, it is so limited
> for what we want to use it for... I've a huge list of improvements for
> JAXB ;)
> 

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

https://lists.sourceforge.net/lists/listinfo/resteasy-developers

I need to refactor it yet again to make it easier to configure.

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