InfoQ's recent post on REST-*.org, which covered the announcement of REST-* and some of the community response to it, has drawn many responses. Changes have also been made to REST-*.org as a result of some of the feedback. Infoq had a chance to interview Bill Burke, a lead for the REST-* initiative, to learn more.
InfoQ: Can you please tell us a bit about your background?
I'm currently a Fellow at the JBoss division of Red Hat. In the past I've work on clustering, EJB containers, AOP implementations, and app server kernel development. I’m currently leading the RESTEasy project and am also driving REST-*.org. Finally, I've also published a few books and have a book on JAX-RS coming out by O'Reilly in November 2009.
InfoQ: What brought you to embrace REST?
It took me awhile to embrace REST as a viable way of implementing distributed systems. I see this same uphill battle whenever I evangelize REST to others at JBoss as well as the Java community in general. Initially I saw REST as a way to do true interoperability between platforms and languages in a very simple, lightweight way. As I learned more, I realized that beyond interoperability, the architectural principles of REST would allow app-developers to create a greater decoupling of interactions between services and applications.
InfoQ: Can you elaborate on the last point? How, in your mind does REST provide better decoupling?
I think the key principle is that RESTful systems are driven by media types and the hyperlinks between them. Clients can ask for the data structures they know how to interact with. The data returned contains all the information (hyperlinks) the client needs to know to interact with the server. New media types can provide additional links as new features of a system come online.
This is how I want to structure the specifications we’re creating at REST-*.org. When defining interfaces to middleware services there are always a lot of edge cases that tend to bloat the API. What I want the core specifications of REST-* to focus on is core resource and link relationship definitions. Basically I want to define a framework and guidelines for specifying new media types for each of the domains REST-* is creating specifications for. This will give the community a lot of room to experiment with different data formats which will in turn will help us fine tune the core model.
InfoQ: In your excellent presentation during JBoss World you tried to compare SOA with ROA. Can you elaborate on that?
When I was putting together the first draft of my JBoss World presentation back in January (I’ve used iteration of this presentation at various conferences), I came across a nice presentation on InfoQ by Anne Thomas Manes talking about SOA Governance. In it she talked about the importance of constraints when deploying SOA to your organization. Without constraints it becomes exponentially hard to manage, integrate, and re-use services as more and more applications come online in your organization. REST is all about defining constraints on your distributed interface. Since it is such a powerful tool for decoupling it makes perfect sense to promote it within large organizations. If you combine this with the ubiquity of the HTTP protocol, you can add true, lightweight, interoperability in the mix as well.
InfoQ: In many of your presentations and posts you emphasize the role of the HTTP protocol for REST. Do you consider unreliable connectionless HTTP the main service communication media going forward?
As Roy hammers over and over, REST isn’t confined to HTTP. That being said, there is no other ubiquitous application protocol that can replace it at the moment to achieve true, lightweight, cross-platform interoperability. HTTP will have to be the workhorse until something new comes along. As REST evangelists say, the Web has done pretty well for itself.
InfoQ: You have been arguing several times, that one of the main advantages of REST is the fact that it is much lighter then WS implementations. On another hand, as we raise the level of abstraction, using, for example, JAX-RS, it becomes significantly heavier. For example, Rest Easy is shipped as 38 jars. Do you think this trend is going to continue and the size of REST stack will catch uo with WS stack?
Doing HTTP invocations within a RESTful environment is much lighter than a WS-* one. The main reason is that WS-* requires an envelope format in addition to HTTP just to send a request. In other words, WS-* tunnels an additional protocol over HTTP. This WS-* protocol needs to be defined using WSDL in addition to the definition of all your media types. With REST you’re just defining your media types. The operations and message format are already pre-defined.
Although a REST stack may grow and catch up to a WS stack in size, it need not be too complex to implement from either an application perspective or a stack-provider perspective. The decoupling and dynamic nature of REST combined with HTTP content negotiation can provide a means to keep the base interactions and media types simple, but provide hooks for more complex protocols to be snapped on through the creation of new media types and link relationships.
But, to be fair to RESTEasy, it’s core really only has a few dependencies that any other Java project might have: a servlet container, logging API, and a HTTP client library. The rest of the jars deal with how RESTEasy integrates with other component models (Spring, Guice, and EJB for example) as well as supports data formats like JSON, XML, Multipart, Atom, and XOP through the use of popular third-party libraries like Jettison, Jackson, James, Abdera, and JAXB. There’s absolutely no reason you can’t develop RESTful services using a vanilla servlet container, but I guarantee you’ll be using many of the third-party libraries we ship with.
We’re pretty much mavenized anyways, so you can pick and choose the dependencies you want to pull in.
InfoQ: Many argue that the foundation services interoperability up-front contracts and the early validation. What do you think REST answer to this? WADL?
No, I do not think we need a WSDL equivalent. In REST, interactions are defined by the media types and link relationships that are exchanged between the client and server. In other words, the exchanged media type is the contract.
InfoQ: Many argue that one of the main advantages of REST is the limited amount of methods, which means that the required action is often has to be “encoded” in the service payload. Do you think that 4 is an optimal number of methods?
Firstly, actions should never be encoded within a payload in REST. Clients should be modeling actions as state.
But, I think you’re talking more about the uniform interface constraint of REST? SQL only has 4 methods can model quite complex interactions and applications. But, to answer your question, are PUT, POST, GET, and DELETE enough? I think for most systems they are. I do think there is potential for OPTIONS, which could be used for service description. LINK and UNLINK might have interesting use cases when you have clients that just want to relate resources to one another through links.
InfoQ: So what are the aims behind REST-*?
Our goal is to figure out where traditional middleware services like Workflow Engines, Business Process Manage, Message Solutions, and even Transaction Managers fit into RESTful architecture and applications. We'll be doing this by defining a set of specifications and guidelines that define interfaces for these services. One thing we will not be doing is defining the meaning of REST or general RESTful guidelines. This is best left to the heavyweights in the REST community. We will be focusing on enterprise middleware because that is our area of expertise.
InfoQ: Some in the REST community believe that everything you need to do enterprise distributed computing already exist within REST and HTTP. So why do we need REST-*?
Much of REST has been described with using the Human Web as an example. By "Human Web", I mean browsers and the humans using these browsers. How machine-based clients interact with a REST architecture is, IMO, very much in its infancy. Enterprise IT is used to using specific sets of middleware technologies to implement their distributed applications. The advent of REST gives us a chance to rethink how traditional Enterprise IT development intersects with middleware. This is what REST-*.org is trying to solve. In the end we may discover that REST is the death of middleware, but my guess is that the answer is somewhere in the middle.
InfoQ: How do you see REST-* evolving in the future?
We'll first start out by defining a set of services we want to create RESTful interfaces for as well as what specific problems each of these services will solve. Out of this effort we'll also hopefully get a set of general guidelines that can be used across the domain we're defining specifically in areas like security. When we feel we have something solid enough to publish, we'll bring our work to standards body like IETF or the W3C.
InfoQ: What's the process for getting involved? For instance, is it open to individuals or just vendors?
REST-*.org is a set of open source projects whose goal is to define specifications and guidelines. Everything we publish will be open source licensed. Currently we've chose ASL 2.0, but we're open to change the license to something else.
Since we're running REST-*.org as an open source project, everything we will do will be done in the open. Any individual or organization can participate. All they have to do is subscribe to our mailing lists. We also hope to get external companies and/or individuals to drive some of our specification efforts. While Red Hat is jump-starting this effort, we don't think it is appropriate for us to be the primary driver behind these efforts.
InfoQ: What future do REST and REST-* have within JBoss?
We've found that using traditional methods to define our distributed interfaces for management and tooling has been just too fragile and hard to manage as our products have evolved over time. Many engineers have been looking for a better way. I think REST can solve some of these problems. We're already seeing some benefits to applying REST to the management interfaces of some of our products. I hope to see it also have a positive effect on how we configure and provision our projects and products.
As for REST-*, we'll be prototyping initial implementations of our specifications under the RESTEasy open source project. This will provide us with a valuable feedback loop by putting our ideas into action.
InfoQ: Any final words you'd like to say?
Distributed computing for years now has seemed like an endless repackaging of the same old ideas, patterns, and technology. Through REST, I finally feel like distributing computing is evolving and moving forward again. While REST won't solve world hunger, it will certainly give us a new perspective to practice software engineering.
