BT

Bill Burke Discusses REST-*, SOA/ROA and REST

by Boris Lublinsky on Sep 25, 2009 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

repackaging the same old ideas, patterns, and technology by Jean-Jacques Dubray

>> SQL only has 4 methods can model quite complex interactions and applications.

yeap, this is so true that we had to come up with stored procedure or Enterprise Java. Bill, have you considered how much coupling these 4 methods introduce between the "client" and the "server"?

Have you considered standardizing REST-QL? there are so many URI syntaxes out there, that it would certainly be worth the effort. On the other hand, REST has no semantics for partial updates, so a spec like REST-DO (data objects) would be very useful to plug that hole.

>> Clients should be modeling actions as state.
In the end, you are not "modeling", you are merely encoding actions into state, and encoding means that you'll simply "repackage the same old ideas, patterns and technologies".

The real way to move forward in middleware is to consider that there is no one concept that can win, not everything is (distributed) object oriented, or just service oriented, or just event oriented, or just resource oriented, or just process oriented. You will make progress in middleware once you will acknowledge that indeed services, events, resources and processes are separate entities and they all needed to be treated differently both in the programming model and at the protocol level.

You will also need to understand that decoupling does not come from the lack of contract but simply from the ability to "assemble" pieces of code that were written by different people, at different time and using different technologies, security models and what not. A key part of this statement is having the ability to keep the assembly operating as the code is changed by one party. The browser can "assemble" a bunch of things and offers a nearly infinite decoupling with pretty much every piece of code written in the universe. When the client is not a browser, your capacity to "assemble" things is greatly reduced, not to mention version these things.

Anyways, your initiative will certainly make it clear that Roy's REST applied outside the browser, is the same old middleware.

Re: repackaging the same old ideas, patterns, and technology by Bill Burke

JJ, to respond to your well thought out response I'll just quote myself from above:

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

Re: repackaging the same old ideas, patterns, and technology by Jean-Jacques Dubray

>> The advent of REST gives us a chance to rethink how traditional Enterprise IT development
>> intersects with middleware

Bill you don't need to rethink anything: as long as "SQL only has 4 methods can model quite complex interactions and applications" and you can "model actions as state", you have for sure the foundation of an "Enterprise IT development".

Indeed, REST shows that there is a real and tremendous value to harvest when building middleware for a given (well thought out) programming model (hint, OO is not the right one for Enterprise IT development). This is the major contribution of REST to middleware. Unfortunately, a lot of people, including you, look at REST and claim that since by adopting a REST-based programming model you get a great piece of mdiddleware for free, REST's programming model MUST-BE-THE programming model that everyone must use.

I am not advocating for anything else other than defining an Enterprise class programming model and designing the middleware together. Surely that's a bit more work than PUT/POST/GET or DELETE some undefined XML fragments. As long as middleware "experts" will think of middleware as a subsystem of the programming model, we'll stay in this architectural vortex, and REST-*, REST, WS-*, E-*, *-*, won't solve anything.

Roy et al have succeeded where all the others have (partially) failed simply because all the pieces were designed together: the system (resources), the protocol, the programming model (Resource representations + HATEOAS). You could easily argue that nowhere else anyone had the luxury to do that and as long as you'll design these pieces individually you'll fail. Since Roy himself tell you that a lot of things that you are trying to accomplish are not RESTful, maybe just maybe that could be hint that you are indeed in a different context. That indeed your resources are not Roy's resources, that the protocol that suits Enterprise IT Development is not HTTP and that HATEOAS is not the programming model.

Anyways, we'll speak again in 5 years. I will however notice that since now REST has become mainstream in the last 2 years, you would think by now, examples of RESTful Enterprise IT Development would show up everywhere. If it was that productive, someone would have built REST-CRM or REST-ERP. Sure lots of APIs have been made somehow RESTful, but I am yet to see an entire enterprise application built in a RESTful way.

Re: repackaging the same old ideas, patterns, and technology by Peter Rajsky

Jean-Jacques,
You really need to change your mindset! And you should stop this heresy! In our new, happy RESTful future, there is no place for RESTless people like you...
You should not ask, if REST solves your problems. It is totally wrong question! Select REST and find your NEW RESTful problems.
My goal was explicit up-front contract and it was really difficult - canonical data models, semantic annotations, procedural contracts (e.g. WS-CDL)... Lot of work needed to be done. But life is so easy with REST - "media type is the contract!"
I am much happier now!

Re: repackaging the same old ideas, patterns, and technology by Jean-Jacques Dubray

Peter:

thank you for your advice, but I know all too well where our industry will end up, we have been in this vortex for at least 20-30 years. REST is simply no different.

Again, show me a single enterprise class app written in a RESTful way and we'll talk again. I don't care about a few GETers and PUTers mashed up here and there. Sure that's useful, but who has used HATEOAS to build an ERP, a PLM or even a CRM. CRUDing at the Data Access Layer is the problem, not the solution. Pushing millions of enterprise developers to encode semantics by hand is the worst advice you can give to them.

I have added a few more thoughts here.

Re: repackaging the same old ideas, patterns, and technology by Bill Burke

JJ, REST is only at the beginning of the adoption curve, so your claim of "show me the money" is a little bit premature.

Re: repackaging the same old ideas, patterns, and technology by Jean-Jacques Dubray

but of course :-)). I have had major discussions on this topic since 2004. REST has become mainstream enough since 2007 that you guys should be able to show more than a couple of URI syntaxes and Java annotations as evidence.

Look, REST is good for a few things, as I said it shows the way to design better middleware by intimately designing the protocol and the programming model together. I understand why Yahoo, Google and a few others love it. All this is fine.

So, why don't you guys come back when there is actually something to show for "Enterprise IT Development". We are a bit weary of the "4 verbs" and "just a bunch of encoding" story. That really sounds like a broken record right now.

At the end of the day the enterprise suffers from two things:
a) corny programming models
b) abysmal middleware capabilities

Why not fix both?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT