Guilhermesilveira's Blog

as random as it gets

RESTEasy: Where did the hypermedia go to?

with 15 comments

Some friends have asked what are the major differences between Restfulie and RESTEasy client frameworks.

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 ignoring the power of hypermedia content on the client side, thus being level 2 according to Leonard Richardson, and not matching Roy Fielding’s description.

RESTEasy is not Roy’s REST

According to Roy Fielding:

But hypertext as the engine of hypermedia state is also about late binding of application alternatives that guide the client through whatever it is that we are trying to provide as a service.

And any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type

Guess what? 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.

Going further:

It is fundamental to the goal of removing all coupling aside from the standardized data formats and the initial bookmark URI.

Restfulie provides a way to access only the initial bookmark URI, everything else is derived from navigating through your resources and its states.

Roy’s dissertation puts his believe quite clear in hypermedia being an important point of the web in chapter 5, his first paragraph: “Representational State Transfer (REST) architectural style for distributed hypermedia systems”.

RESTEasy got it right when it allows the user to access multiple URIs and the http protocol as the application protocol. But it still helps creating strongly coupled systems. Those who use JAXB (JAX-RS required) and fixed xml schemas do not allow server to evolve without prior notice to their clients. Ian Robinson has written about links in his blog and – another option – contract based systems in ThoughtWorks Anthology.

Back in 2007, there was a nice discussion on SOA allowing the users to create strongly coupled systems, where Mark Baker cleared it: SOA is constraintless, therefore one can create strongly and loosely coupled systems.

RESTEasy not supporting hypermedia content by default matches Roy’s definition of unrestful:

In other words, not RESTful at all. REST without the hypertext constraint is like pipe-and-filter without the pipes: completely useless because it no longer induces any interesting properties.

Although RESTEasy supports atom feeds, which is a good point, if the client wants a real hypemedia aware resource, he has to work on the deserialization process on his own.

RESTEasy does not provide the class generation mechanism that Restfulie (both Java and Ruby) provides so end users are able to transverse your resource’s tree and states without prior knowledge of every other URI.

According to Roy, one of the key benefits of the REST archicture style is its visibility through out the entire layered system:

REST is an architectural style that, when followed, allows components to carry out their functions in a way that maximizes the most important architectural properties of a multi-organizational, network-based information system. In particular, it maximizes the growth of identified information within that system, which increases the utility of the system as a whole.

By fixing all URI’s on the client side, along with not supporting hypermedia content by default, RESTEasy provides less information to layers contained between the server and the client: thus less visibility.

Server side

The same issues arrive when talking about the 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.


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.

Written by guilhermesilveira

December 3, 2009 at 6:05 am

Posted in java, restful, ruby

Tagged with , , , , , , , , ,

15 Responses

Subscribe to comments with RSS.

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

    John Nackman

    December 3, 2009 at 1:56 pm

  2. Hello John,

    You are right, the text only mentions about RESTEasy being a JAX-RS implementation when JAX-RS implies into some decision: JAXB support by default.

    JAX-RS do not imply in any specific client API, therefore the no-hypermedia support requirement was a JSR decision (lack of time from what I’ve heard).

    From the implementation point of view, they were/are free to support and move on.. but then it was a implementation’s decision not to support it.

    In the end, both the JSR and the implementations decided not to support hypermedia: its objective implications are much better exposed by Roy’s post and Leonard’s presentation than I probably could.

    Jim Webber put a little bit more thought on “being a JSR” implementation implications:

    Whether good or not, the standard will help developers doing something a little bit more “rest”-alike, but not enough.


    December 3, 2009 at 2:25 pm

  3. Trashing somebody else’s framework to promote your own usually isn’t a good way to go about launching your own framework. I’ve made the same mistake myself in the past and trust me, it is the wrong way to go about things. Anyways…

    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. (This is one of the reasons I never liked something like Restlet).

    Given that JAXB is not the only Object model we support. We support a multitude of marshalling frameworks and media types.

    For hypermedia, we do have support for Link headers, and have helper Link objects that fill in base urls automatically for you when you marshall them back to the client. IMO, if the developer wants some media type support that is more funky, then they should write something. JAX-RS has complete support for plugging in your own marshallers.

    Finally, this idea that XML schemas are unRESTful is completely *ABSURD*. You can design your XML schemas to be both flexible and backward compatible (and I suggest as much in my book and have written about it multiple times on my blog). Schemas exist to define a contract for the XML document. Companies, users, developers desire this contract. Machine-based clients require certain guarantees or they just will not work. Schemas provide self-documentation for a message. They also give educated hints for tools and frameworks so developers on both the server and client have an easier time to develop their software.


    December 3, 2009 at 2:41 pm

  4. I’ve performed some Hypertext oriented additions to RESTEasy server and client… I’ll respond fully once I’ve digested what you’ve said, but for now, take a look at these links:

    Solomon Duskis

    December 3, 2009 at 2:59 pm

  5. I think it would make more sense for you to compare restfulie with JAX-RS and not one specific implementation of it.

    John Nackman

    December 3, 2009 at 3:38 pm

  6. You’ve made some bold statements here, and they have merit. Are you open to a public dialog on Google Wave on this subject?

    Solomon Duskis

    December 3, 2009 at 3:59 pm

  7. Hello Solomon,

    The second post really helps – on the server side – using hyperlinks as to guide clients on following resources and states. I believe Ian’s post can help further on allowing schemas to evolve in a forward-compatibility mode in an easier fashion.

    The example in post assumes the existence of such resources, would it be easy to implement links to non-existing resources? (i.e. create-artist within a store resource)



    December 3, 2009 at 6:12 pm

  8. Hello John,

    It makes sense, some of the comparison could be to the JAX-RS itself, not the Resteasy implementation. Thanks


    December 3, 2009 at 6:12 pm

  9. Hello Bill,

    I did not mean to trash it by any means. As you have pointed out, RESTEasy and JAX-RS help, as it provides their users the flexibility to implement hypermedia support or not and how to do it: design your schemas in a flexible way or not and so on.

    Those are the advantages of not forcing some constraints. The points that I mentioned are the disadvantages of doing so (leaving it to the end-user).

    I find Ian’s discussion on the TW book nice when explaining schema evolution and schematron’s usage, as you have pointed out, thanks.


    December 3, 2009 at 6:16 pm

  10. […] Bill Burke pointed in a comment, “you can design your XML schemas to be both flexible and backward compatible ” and […]

  11. I looked at your stuff in more detail. You have some interesting ideas, but I wonder how well they hold up when the client or server has to deal with extracting and setting headers, handling errors, handling (or not handling) redirection, conditional gets, puts, and posts, POE. In these scenarios, things start to not look so client and you end up dealing with Request and Response objects. At least, thats my experience so far as I’ve tried to evolve and use RESTEasy in scenarios.


    December 8, 2009 at 2:19 pm

    • Should be “things start to not look so clean” Apologies for typo.


      December 8, 2009 at 2:20 pm

  12. Thanks for the feedback Bill,

    You are right, in some (a lot of?) situations, we need to allow further access to request and response details.
    Right now, only some issues you mentioned have been solved (setting and extracting headers, handling – or not – redirection and conditional gets).
    Other conditional invocations and handling errors is still lacking good support.

    In these scenarios, things start to not look so client and you end up dealing with Request and Response objects. At least, thats my experience so far as I’ve tried to evolve and use RESTEasy in scenarios.


    December 8, 2009 at 4:58 pm

  13. […] única limitação é que esta representação XML não nos diz nada sobre quais ações estão disponiveis para o […]

  14. […] xml podem ser usados de maneira a garantir flexibilidade e compatibilidade, mas não é o comportamento padrão de tal ferramenta: depende muito mais do usuário conhecer e […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: