Back in November we reported on the release of the Restfulie project, a framework for creating hypermedia aware clients and services. Recently Guilherme Silviera, the creator of Restfulie compared his project with RESTeasy, one of the JAX-RS implementations, and questioned whether RESTeasy (or even JAX-RS) was the right basis for building RESTful applications. This caused some discussion in the community so we took the opportunity to interview Guilherme to try to put things into context.
Infoq: Hi Guilherme. Can you start by giving us some insight into what caused you to develop restfulie?
Guilherme: Jim Webber, Savas Parastatidis and Ian Robinson will release a book on using the web as one's infrastructure in early 2010 and after reading it I finally got to understand how hypermedia fit into the rest scene. Going back to some of Roy's and Subbu Allamaraju's writings and the JAX-RS implementations, we realized that much emphasis was put into the HTTP and URI parts of the web but not that much in its hypermedia nature (as Richardson pointed out @qcon 2008). So we created Restfulie as a way to focus first on the hypermedia aspect, then on http and uris.
InfoQ: How big is the Restfulie community?
Guilherme: Restfulie has been around for a short time so the community is small so far: but it has attracted positive comments of names I am fond of. Contributions for the Ruby release are coming in and we have been collecting feedback from some users. Jim Webber helps us in the theoretical and real life issues. Both Jose Valim and Yehuda Katz, some of the guys behind rails 3, have also given us feedback which allows us to keep improving. Brian Guthrie and Fabio Akita - well known on the ruby community - also contributed with both code and dsl ideas.
InfoQ: What do you think about standard, since your post is really about restfulie versus JAX-RS?
Guilherme: That's a nice point. Thinking about successfully released JSRs Hibernate/JPA always come into our minds. JCP first attempt to do some kind of ORM was JDO, and JDO never attained Hibernate' s success for many reasons. In my opinion, one of the main reasons for this to happen is the top/down approach: trying to specify a new JSR without an already proven solution api as a guide in JDO's case. When Gavin King helped to lead JSR 220, they came to JPA 1. JPA 2 dig further into Hibernate proven capabilities, specially about the Criteria API. i.e.: A question to be answered: will the developers prefer to use Hibernate-style Criteria throug Strings, or will they use the newly created StaticMetaModel approach for type safety?
So we all have seen what happened to comitee-led standard technologies versus others (as Hibernate/JPA and probably Seam/CDI(formerly WebBeans) which bring ideas from a successful API into the JSR. Standards are really important, but it is time that we learn from our mistakes. In JPA and CDI cases, JBoss brought its experience from existing and successfully adopted API's into JSRs. InfoQ just posted Rod Johnson's presentation which enphasises it: "Rod Johnson ... presenting the lessons to be learned from its failures, like committee-led standards ... preparing to avoid such mistakes in the future."
Speaking about Restfulie, after receiving the feedback from the post, and as Jim Webber was the first to respond at his blog, "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". The REST world should be thought about with even more care. The JAX-RS specification puts a lot of value into HTTP and URIs but leaves a lot of space for hypermedia constraints. Every other JAX-RS implementation deals with almost everything related to hypermedia in its own desired way and, as the specification has "forced", their focus is put into the HTTP+URI support. As Roy points out, HTTP is our API, so maybe a bald statement would be to say that there should be no other standard api built using it.
InfoQ: Have you thought about contributing to one of the JAX-RS projects instead of developing a separate RESTful framework?
Guilherme: Restfulie was born within the Rails environment so it was not really a point to think about during its conception. Working in a teaching company, we know how important it is for those who are learning to be exposed to the most important ideas as soon as they start, as the first impression of a technology will influence the way the client uses it. We do not follow the standard path of JAX-RS (and implementation) based docs: uri + http, much later hypermedia and later on client support, expecting that in this way we can shape their thoughts better on hypermedia importance - and http and uri.
Focusing on hypermedia first, uri's and http needs comes more naturally: the feedback that we get from clients is that they are using the hypermedia aspect of REST, so it seems clients are understanding and taking advantage of the hypermedia approach. The java version and how it could relate to the JAX-RS standard is addressed in the next question.
InfoQ: What next for restfulie?
Guilherme: We just released a Java version (vraptor and hibernate), focusing in the hypermedia constraint. When vraptor3 came out, we were not sure whether it should be a JAX-RS implementation or not. Its important to have the standard, and equally important to have other frameworks which give new ideas to the market. That's where I believe Restfulie (and thus vraptor) fits in right now. This might change in the future if we find out that this is really a better way to create systems: the java version could also join strengths with some implementation, as long as it does not lose the hypermedia focus.
Some rails 2 version refactoring, Rails 3 and .NET implementations, support to a lot of http headers and response codes on the client side (server side is supported already). The client part of restfulie is the one which amazes me the most, it has a lot of neat features related to dinamically binding URIs by default and state transitions instead of just being a "serialization tool over http" (i.e. jaxb + httpclient or other providers).
InfoQ: Thanks for taking the time to answer our questions.
Guilherme: Your welcome.