Is JAX-RS, or RESTeasy, un-RESTful?

Posted by Mark Little on Dec 08, 2009

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

REST ,

Java ,

SOA

JAX-RS has been a standard for over a year and in that time there have been a number of implementations, such as RESTeasy, CXF and Jersey, the reference implementation. At the time it was finally ratified, Stefan Tilkov interviewed the specification leads, Marc Hadley and Paul Sandoz about their view on JAX-RS.

When the JSR was initiated, there were some doubts in the REST community about its chance of complying with REST’s key principles.

Marc thinks this goal has been met: I think the API encourages a resource-centric view and makes developers think about the identifiers of their resources and the methods they support. Declarative support for content negotiation works well and the default resource life-cycle encourages a stateless approach. If I had to identify a weakness it would have to be limited support for hypermedia as the engine of state - whilst we provide good support for extracting information from request URIs and building URIs to resources, its still very much left to the developer to use hypermedia in representations appropriately.

Paul agreed: Yes, this is probably the hardest area. JAX-RS provides a bunch of ways to construct URIs but there is no such URI binding facility with a modeling API, such as JAXB. I think there are some aspects we can explore in this respect, for example Henry Story’s RDF serialization.

The Java community has certainly seen an increase in the number of projects based on JAX-RS over the past 12 months and most people see this as a step in the right direction. However, not everyone agrees and recently Guilherme Silveira, the lead of the restfulie project, posted an interesting article comparing and contrasting his project with RESTeasy, though as several of the comments later pointed out, this should have more accurately been about JAX-RS and not any specific implementation. According to the resfulie site its aims can be summarized as:

CRUD through HTTP is a good step forward to using resources and becoming RESTful. Another step further into it is to make use of hypermedia-based services and the Restfulie gem allows you to do it very quickly.

In his posting, Guilherme points out several issues with RESTeasy [JAX-RS] that he believes makes it un-RESTful and which restfulie does not follow:

• Strong coupling and hypermedia awareless: "As of today, Resteasy requires you to create an interface mapping every resource operation to a specific method, using @VerbName and @Path annotations to specify the desired target URI."
• RESTEasy is not Roy’s REST: According to Guilherme RESTful systems should not use early binding, which encourages strongly coupled systems. "Java interfaces with @VerbName + @Path annotations means early binding, means an effort trying to describe which methods to use on which URI’s: tighter coupling, less space to evolve your server systems."
• Server side: "RESTEasy does not provide any default interface for hypermedia content, but JAX-RS default support to JAXB: plain xml. It is up to (good) programmers to know how to make use of hypermedia systems in order to create a loosely coupled system."
• Language: "Another key point on Restfulie’s approach is that it is Java-INdependent. Every month we see a larger number of integration software being developed in other languages: Restfulie can already help Java and Ruby developers."

Jim Webber, whose writings have influenced restfulie, picked up on this posting:

Overall I think the theme of his analysis is accurate: RESTEasy doesn’t provide support for hypermedia out of the box, and that means it’s anything but RESTful.

However, he does go on to say:

But I don’t believe this is RESTEasy’s fault. In fact in the bizzaro-world that RESTEasy inhabits, I imagine it to be an exemplary citizen. Caught between the enterprise and the JCP, what choice would a sensible Java vendor have, other than to follow (and influence) the appropriate JSR? So it’s not RESTEasy (or Jersey, or CXF) that are at fault here, but the committee-driven process where folks with different goals and levels of understanding about REST have convened to drive out a lowest common denominator called JAX-RS (a poor name since at best JAX-RS provides a programmatic layer over a Web server).

Bill de hora in a comment to the post disagrees:

I've read this post and Guilherme's, looked at his framework and there's not much beef. I learned that JAXB == bad, but I use Jersey all the time on the server and on the client and have never used or had to use JAXB - that's internal to the implementation (transformation sugar for crappy type systems). Couldn't we taking potshots at almost *any* other "web" framework? Just think of the fun we could have with HttpClient or java.net.*. Just today I whipped up some nice client code on top of Abdera and Jersey client where the low level stuff is driven by links. It all works. If the problem is that the OO paradigm simply sucks for hypertext driven systems I'd buy that...

And Stefan Tilkov adds:

Restfulie makes some very specific decisions and comes up with a solution that is RESTful. But it's not a generic framework for building (any kind of) RESTful system. I don't think they compete, they address different problems domains.

And as John Nackman mentions to Guilherme on his original post ...

Interesting, but this isn’t really an objective analysis is it? At least on the part of RESTEasy you ignore the fact it is based on a standard. Or do you think that standards are not important for developers? I think a more thorough and objective discussion would be beneficial to the community as a whole.

So apart from stirring up a lot of discussions around whether or not the original article was accurate, does this mean JAX-RS has left too much unspecified? Are developers assuming too much from the current implementations? We'll give the last word to Bill Burke, RESTeasy lead:

RESTEasy and JAX-RS exist to help you write RESTful web services and clients. It is a tool. Hypermedia tends to be very application specific, so, IMO, there is only so much a framework can do before it starts to intrude too much into the design of an application. REST is architectural guidelines to help you write distributed interfaces. REST is not guidelines to help you write and design code. I got involved with JAX-RS because I thought it was the least intrusive way to help you write RESTful services. It gives developers a lot of flexibility on how they *implement* their RESTful services. IMPLEMENT is the KEY WORD here.

Note, we will be posting a separate interview with Guilherme later.

1. Back to top

   a better view on jax-rs support to resources and hypermedia

   by Guilherme Silveira

   Paul and Marc's (spec leads) comments helped me to understand: JAX-RS helps with some keypoints in rest based systems and there is still room for improvement in the hypermedia space.
   
   As Mike said: "does this mean JAX-RS has left too much unspecified? Are developers assuming too much from the current implementations? " and Bill's: "It gives developers a lot of flexibility on how they *implement* their RESTful services" its up to the developer.
   We are looking for something that "constrains" the developer to be restful, so it seems its two different paths as Stefan mentioned. Nice summing up.

   Reply

2. Back to top

   Re: a better view on jax-rs support to resources and hypermedia

   by Ryan Riley

   We are looking for something that "constrains" the developer to be restful, so it seems its two different paths as Stefan mentioned.

   
   
   I think this is the key point. If you don't worry about the constraints and leave that up to the developer, then almost any platform out there could be considered "REST ready." However, many platforms and frameworks don't nudge developers in the right ways, and we have far too much inaccurate information out there regarding the REST constraints. For a framework to live up to the REST name, it should really push developers toward the constraints. Otherwise, it's just another framework. At best, it's CRUDEasy, though certainly REST is possible.

   Reply

• Older >