DZone recently spoke with JBoss Fellow, Bill Burke on a range of RESTful topics, including REST-*, an open source project aimed at defining new standards, guidelines, and specifications around RESTful programming. According to Bill, REST-* addresses many of the problems inherent in the SOAP standard, where it's hard to both implement an application, implement a standard, and to interoperate between different vendor implementations. SOAP also uses HTTP primarily as a connection protocol, and fails to leverage all the 'rich' features offered by the HTTP protocol, such as caching and content negotiation. Bill talks about these and other issues.
The complete transcript of the interview has been provided below.
DZone: Bill, can you tell us a little bit about what you're up to at JBoss?
Bill: Currently I'm working on strategies for providing RESTful interfaces to our products and projects. One focus of that is a project called RESTEasy, which is a JAX service implementation, which is a new Java API from the JCP that allows you to write RESTful web services.
DZone: Can you give us some background on how the project came to be and some of the motivations behind it?
Bill: Well, a couple of years ago I was talking to some people outside of Red Hat and JBoss about the direction that web services and SOA were taking. I was introduced to the concept of REST as a way to design and implement web services in general. I started looking into it. I started comparing it to SOAP, and WS-* and that sort of thing. I thought that was the direction we should look into. I thought a great way to look into this stuff and get our feet wet into the REST community was to implement a new specification that's going to be in EE 6. It's called JAX-RS. That's really where RESTEasy started.
DZone: What is JAX-RS?
Bill: Its fundamental goal is to write RESTful web services more easily. Really what it is is it's a simple annotation framework that allows you to map an incoming HTTP request to a Java method call. What you can do is you can pull pieces out of an HTTP request ad hoc using injection annotations. So what your RESTful Java classes look like are business logic annotated with JAX-RS annotations pulling in the relevant data from the HTTP request.
DZone: Does the HTTP protocol provide sufficient functionality to allow applications to scale?
Bill: Yes, I believe so. For the past five to six years, web developers have really only been using a very tiny subset of the HTTP protocol. HTTP is actually a very complex application protocol. For instance, technologies like SOAP have only really used HTTP as a connection mechanism. HTTP has really nice features, really well-defined features like caching content negotiation where you can ask a server what data type you want back. Really, things like that allow the web to scale and allow your applications to be very flexible when you're implementing and you're evolving your applications over time.
I think the web in general - if you think about the web, it is a huge distributed system. It's all over the world, billions of transactions and requests per day. It has scaled from a small, small set of networked computers at DARPA to what it is today, and it has because of a set of core principles.
That's really what the REST movement is all about, taking the architecture of the web and trying to apply it to your applications. It has already proven itself to be able to handle this type of load.
DZone: Amongst the JAX-RS implementations available today, what differentiates RESTEasy?
Bill: I think there are a few features. One of the things that's in the Servlet 3.0 API is the idea of asynchronous HTTP. The idea is that you can have one thread handling the incoming request and a different thread can handle the outgoing response, so you can detach request processing so that you don't have a thread-per-connection problem. What RESTEasy has done is that right now, the Servlet 3.0 specification isn't finished yet, and there have been a number of proprietary implementations, both in open source and in the commercial world.
What RESTEasy has done is written a very simple abstraction over that stuff so that if you're using Jetty, or JBoss Web or Tomcat, RESTEasy can provide a JAX-RS friendly API for asynchronous HTTP. That's one thing we have.
We also try to take advantage of some of the other JBoss projects like JBoss Cache. What we've done is we've written a client-side and a server-side HTTP cache. On the server side, it's local to your applications so that when clients invoke a new request on your JAX services, it can avoid invoking business logic if you've set up the appropriate caching policies.
On the client side, the JAX-RS specification hasn't defined a client API. RESTEasy has to find a nice client API, both a programmatic one and a proxy-based one, where you can use JAX service annotations on an interface. Instead of mapping an HTTP request to a Java method call, the RESTEasy client framework, what it does is it maps a Java method call to an HTTP request.
On our client framework we also have a browser-like cache for our client API so it can handle basic HTTP caching semantics.
DZone: What component models does RESTEasy integrate with?
Bill: Yes, we integrate with most popular component models. We have deep integration with Spring. It's pretty seamless. All you do is write Spring beans and annotate it with JAX service, and it'll automatically get published as a JAX service. We have integration with EJB, nice integration with Seam, and integration with Google Guice as well. We'll be looking into integrating with Web Beans as well when the specification is final.
We're trying to be friendly to all component frameworks. We don't want to implement our own component layer. We really want to leverage existing ones and just provide RESTful JAX services on top of existing component models.
DZone: What can we expect to see in future releases?
Bill: One of the parallel efforts we're doing with REST is we've just started an organization called REST-*.org. What we're doing in this organization is we are defining RESTful interfaces for popular middleware patterns like messaging, transactions, security, that sort of thing. What RESTEasy is going to become is an umbrella project which implements these specifications that we're defining in the RESTful community. What I mean by umbrella specification is that RESTEasy can be working with other JBoss projects like Messaging, the Transactions project.
Some of those communities will be doing the RESTFul implementations. What RESTEasy will become is like a profile of a set of RESTful services that we bundle and ship as a project.
DZone: REST-* sounds like an ambitious step. Is this really an attempt to obfuscate the heavyweight WS-* standards approach?
Bill: In most ways, yes. What we're trying to do is create pragmatic, simple interfaces for these middleware patterns that are both easy to implement and easy to use. For example, I just talked to a couple of people at JBoss World recently, and they were saying they were having problems using the SOAP stack on platforms like .NET and having it talk to Java-based SOAP stacks.
One of the promises of REST is that it's very lightweight interoperability between different platforms and languages since you're using raw HTTP to do the communication and sending messages that are XML or JSON-based. It's very easy to interoperate between different platforms as long as a language has an HTTP stack on it. If it has a client API and a server API, you can easily interoperate, so there are not a lot of barriers to entry for somebody to either integrate with a RESTful service or to implement one.
That's the major, major promise I see with REST, where we had problems with the SOAP area where it was hard to both implement an application, implement a standard, and to interoperate between different vendor implementations. That's the major difference I see with REST-* being to WS-*.
Some other things we're going to focus on is WS-* really doesn't take advantage of the HTTP protocol. It really tunnels over it. If you look at SOAP and the WS-* specifications, you'll see that SOAP really only uses HTTP as a way to establish a connection.
It doesn't use HTTP message headers. It doesn't use some of the common things like HTTP caching, content negotiation. All the features that make HTTP a very rich protocol, SOAP ignores.
So what we're going to be doing in REST-* is relooking at these specifications through RESTful glasses, through looking to be able to leverage and take advantage of the HTTP protocol as a whole rather than trying to create a new protocol and tunnel it over HTTP.
DZone: Does a REST-oriented approach fundamentally change the way we should think about our SOA development, deployment and governance models?
Bill: I think the same problems are still going to exist, but because it's easier to interoperate in a RESTful environment, I think people will find it easier to govern these distributed systems mainly because system administrators have been governing HTTP packets for a long time. They have existing tools already. They know how to secure it. They know how to scale it. They know how to distribute it. They know how to handle HTTP packets. Sure, the SOAP stacks are getting better at that sort of thing, but it's simpler in a RESTful environment.
DZone: Will REST-* address all of the use cases that WS-* currently addresses?
Bill: I think it'll address the use cases that are important to manage, and design and develop a distributed system. There are some things that we'll want to leave out, addition by subtraction, and the reason for that is WS-* doesn't have as many constraints on the architecture as REST does. This may not be important for a simple distributed application, but when you start integrating project to project, business unit to business unit, business to business, when your distributed systems start becoming large, it's really important to have well-defined constraints, well-defined guidelines for developing your distributed applications. I think REST provides more strict guidelines than WS-* does.
So, yes, there are things that REST needs to add to its architecture to be able to handle some of the use cases that WS-* currently solves, but we also want to do addition by subtraction as well.
DZone: Can we expect to see RESTEasy included in the next release of the Enterprise Application Platform?
Bill: Yes, RESTEasy is going to be a supported product within our EAP 5 release.
DZone: What are some common projects that I would use in conjunction with RESTEasy? I think you mentioned JBoss Messaging and a few other projects.
Bill: Not Messaging right now. We want to be able to do that in the future. But really you can use it as a better way to write servlets. The Seam integration with RESTEasy allows you to use some of the annotations that are available in JAX service to write your Seam applications. You'd be using it the same way you use JAX-WS with EJB, the same sort of way.
DZone: You also have an upcoming book, "RESTful Java," coming out I believe by O'Reilly Media. What will it cover?
Bill: Yes. What "RESTful Java" is going to be mainly about is the JAX service specification. I go into some discussion on what REST is and how you can implement RESTful patterns within Java using JAX-RS. It's about 250 pages. It also contains a downloadable set of examples for each chapter that you can run with the book so that you can test things out on your own and see things in action.
DZone: Bill, for organizations embarking on their first SOA project, what advice would you give to them in terms of taking a REST-oriented approach vs. WS-*?
Bill: I'm going to be biased, and I'm going to say that I think they should start off with REST. The reason why is that when you're defining RESTful services, you need to define the messages you're passing across. Usually these are XML documents or JSON documents, so you need to define a schema for those in how you interact with that schema. Now if you're finding that you need more complex scenarios that WS-* solves, you can easily take some of that work you've already done for your RESTful interfaces and use it within the SOAP stack, again, for instance, your XML schemas and that sort of thing.
If you're finding that your requirements are not met by a RESTful service, than you can reuse a lot of what you've done in the WS space.
DZone: Bill, what are some of the features you're working on right now in RESTEasy for the next release, and when can we expect to see the next iteration?
Bill: Right now, we're currently focusing on small features, for instance, like adding new data formats that we support and fixing bugs. For the next major release, we're going to focus on trying to move RESTEasy into becoming an umbrella project where we implement some of the REST-* specifications that we're defining, for instance, the messaging, and the transactions, and the security. We want to provide implementation of those within the RESTEasy umbrella project. That's probably where we'll be going with RESTeasy in the near and far future.
DZone: What advice would you give to developers and architects embarking on their first RESTful project?
Bill: I would say read a lot first, especially if you have come from a CORBA WS-* background, because writing RESTful systems is a little bit different. For me, I had to read a lot before I accepted REST as a way to do things. That's because I was a heavy CORBA guy. I was in the past, so I needed to overcome some of the pitfalls that that architecture has that REST solves.
So I suggest reading a lot. A good book is O'Reilly's "RESTful Web Services," Sam Ruby and Leonard Richardson. It's a very good introduction to what REST is. Even Roy Fielding's thesis on REST is readable, for a PhD thesis. There's also the REST discuss group on I think it's Yahoo! Groups.
But I suggest people to read a lot to understand why this architecture is important, because at first you might not see why.
DZone: Bill, on behalf of the DZone community, I want to thank you for your time today.