BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Is REST Winning?

by Stefan Tilkov on May 31, 2007 |

The topic of REST as an alternative way for Web-based integration — as opposed to Web services, which are perceived by a small, but vocal community to violate the Web’s principles — has been debated on InfoQ many times before.

The oldest discussions of SOAP vs. HTTP date back to the year 2000, where #1 evangelist Mark Baker replied to James Snell. As early as 2002, Paul Prescod wrote an article claiming that the principles embodied in the Web’s architecture make it superior to “DCOM for the Internet” (his label for SOAP RPC). Since then, the debate has been going on and on, with a noticeable tendency that more and more experts support either both the WS-* and REST camps. Discussions here at InfoQ with Mark Baker, Sanjiva Weerawarana, and Pete Lacey have received lots of comments, arguing both for and against the merits of the REST approach.

More and more Web services tools, such as Apache Axis2 and CXF, have started to offer some support for the REST model. Sun has started JSR 311 to standardize support for RESTful web applications on the Java platform. Ruby on Rails has supported REST since version 1.2. Most recently, Microsoft’s support for REST made the news.

In February, the W3C organized a workshop where one of the submission papers (by Nick Gall, a Gartner VP) contained the following claim:

Web Services based on SOAP and WSDL are “Web” in name only. In fact, they are a hostile overlay of the Web based on traditional enterprise middleware architectural styles that has fallen far short of expectations over the past decade.

Now a significant statement in favor of REST comes from none other than Burton Group analyst Anne Thomas Manes, who has been one of the most prominent public figures in the Web services space (and also authored a book on the topic):

If you’re ready for REST I suggest you jump on board right away and get ahead of the curve […] You’ll have to train your developers in REST principles. You’ll probably want to adopt one of the new frameworks or help build one yourself to help your developers implement RESTful applications. You definitely need to provide guidance to your people. What you want to do is work to the point where REST becomes the default for all your distributed applications.

Taking off my editorial hat for a second, I fully admit that I am clearly biased towards REST, so possibly I am perceiving this wrongly. It’s also entirely possible that Pete Lacey is right and they can’t hear you. But it seems obvious that REST is significantly gaining mind share among former SOAP/WS-* proponents, and that finally, the vendors have started to support this.

Is REST “Web services done right”, and will the WS-* universe disappear and be replaced by Web technology? Is REST just another technology choice, irrelevant in the larger context? Are Web services based on SOAP, WSDL, and WS-* the obvious, correct and undisputed choice for supporting SOA?

What is your opinion?

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

Absolutely by Alex James

REST is definitely gaining mind share. Without doubt. Microsoft seems to have undergone a fundamental shift in thinking, with Astoria and WCF and they will bring with them developer mindshare as they produce tooling etc, to help the average developer think RESTfully.

The Ruby on Rails crowd are pretty convinced too.

Also it is interesting to note the grudging acceptance from one time opponents. It is as it their the focus has shifted from "is REST better than SOAP?" to "is REST good for transactions?", which sort of implies that they might be ready to concede the first point.

I have a lot more thoughts on REST here.

Is REST the same for everybody? by Ronald Miura

Well, what is REST? Many people seem to call 'REST' anything about 'beautiful URLs', POX, Document-Driven web services, 'CRUD in XML', etc.

Maybe this is the cause of the mind share gaining of REST: each developer picks one or two of the features above, includes it in their application/framework, and call it REST. But how many applications out there really are REST, and how many just follows a subset of its principles? Can we call those REST?

Restlet by Jerome Louvel

Like you, I'm biased towards REST. But what is obvious is the recent turn made by major WS-*/SOAP promoters like Microsoft and Sun. Major companies like Amazon, Google or Yahoo also seem to focus the Web Services APIs on the REST style.

For those looking for a comprehensive and dedicated REST framework for Java, may I suggest them to have a look to the Restlet open source project? InfoQ has recently covered the launch of the 1.0 version.

Re: Is REST the same for everybody? by Jon Crosby

Ronald, REST is REpresentational State Transfer. The best place to go for a clear understanding of is Fielding's dissertation. Unfortunately, those who would use "beautiful URLs" and "CRUD in XML" to define REST are not painting a clear or complete picture. "CRUD in XML" almost gets the HTTP verb part of REST, but misses the fact the XML is just one possible Representation. "Beautiful URLs" is sort of a fuzzy marketing concept, but almost understands the Resource piece of REST, etc. If you read the linked explanation in its entirety, you will be ahead of most. Further, the Restlet project looks to be a fine implementation of the pure concepts.

Nothing is won until the other camp concedes by Noah Campbell

Simply putting a "Mission Accomplish" banner behind your pulpit doesn't signify that you've won.

REST is an approach that makes some things easier and other more difficult. Ask a REST proponent if WS-Security (typically bundled into the WS-* camp) is a complete waste and you'll likely see the REST vs. WS-* debate start to be less black and white.

Since Stefan is requesting opinion, here's mine. REST provides a last mile interaction for consumer facing application architects that are betting on mash-ups to boost adoption. WS-* has it place and will continue to be a workhorse for system integration and new SOA initiatives. REST fits nicely into the WS-* ecosystem. REST will ultimately be consumed in WS-* as seen in efforts by the WSDL 2.0 specification.

REST is still at a very early stage -- but it is thriving by Anne Manes

I don't think it's appropriate to say that REST is "winning". As I indicated in my blog,


REST is not simply technology--it's an architectural style that's fundamentally different from the way most developers design systems today. It requires a noun-oriented approach to designing systems rather than one based on verbs. I know quite a few people that have been studying REST for years who still struggle with RESTful design practices. Understanding the basics of the style is easy. Truly groking it and being able to apply it to real-world situations is much harder.


The steep learning curve associated with groking REST will limit its adoption for at least the next five years. But it is thriving and gaining more mindshare. Unfortunately, as Ronald Miura points out in a previous comment, REST currently appears to be in the eyes of the beholder, and many developers are less than conscientious about enforcing REST constraints.

REST is an architectural style, and for an application to be RESTful, it must conform to the REST architectural constraints. Just because you've created a service that communicates using POX over HTTP, that doesn't automatically mean that the application is RESTful. Likewise, if you create a service using SOAP, that doesn't automatically mean that it isn't RESTful.

I'd like to point out that neither Axis2 nor CXF support REST. They support non-RESTful POX over HTTP. They don't establish a URI for every resource. Instead they create a resource that represents a set of verbs, and then they tunnel RPCs through HTTP GET and POST. (Hint -- if the URL contains a verb and some method parameters, it's not RESTful.) Applications developed with these frameworks do not exhibit the desirable characteristics associated with REST.

Given a choice between a method-oriented system that pretends to be RESTful and one that acknowledges its true nature, I'll take SOAP every time.

Anne Thomas Manes

Re: REST is still at a very early stage -- but it is thriving by Mittal Bhiogade

well I could not figure out difference b'ween POX and so called restlets, can some explain it rather than pointing it out to some dissertation

Thanks
Mittal

Want to be cool? Learn Facebook. Want a career? Learn REST by Chris Marino

It used to be only the cool kids knew REST. Maybe not so much anymore.....

Re: REST is still at a very early stage -- but it is thriving by Dan Diephouse


I'd like to point out that neither Axis2 nor CXF support REST. They support non-RESTful POX over HTTP. They don't establish a URI for every resource. Instead they create a resource that represents a set of verbs, and then they tunnel RPCs through HTTP GET and POST. (Hint -- if the URL contains a verb and some method parameters, it's not RESTful.) Applications developed with these frameworks do not exhibit the desirable characteristics associated with REST.


As a CXF author, I would disagree. Have you looked our annotation & convention based bindings? We allow you to build a java class and map its operations to arbitrary URI/Verb combinations using URI templates. For instanace:

@Get
@HttpResource("/customers/{id}")
public Customer getCustomer(String id)

This will map every access of /customers/FOO using the GET verb to that method. There is no verb in the URI itself. There are annotations for delete, put, and post as well.

We also have a "convention" based binding where we'll look at your interface and construct intelligent URIs for it. For instance, CXF could look at the getCustomer(String) method and it will map it automatically to the /customers/{id} URI. It even understands pluralization rules. So if I have a getPerson() method, it will create a resource at /people/{id} which maps to that method.

We also of course support the simple POX stuff, but we're also working on going way beyond that to support true RESTful services as well (expect things like ETag/LastModified support to come very soon).

We'll know REST has won once... by Joe Holloway

...someone uses it to reinvent RPC once again. Even with the proprietary protocols I work with it seems like there's always someone ready to turn an application protocol into a transport protocol for their own application protocol.

Re: REST is still at a very early stage -- but it is thriving by Stefan Tilkov

I agree that Axis2's "REST support" (at least as it was a few months ago) doesn't have much to do with REST, but I also believe CXF's to be superior (although unless I'm mistaken, CXF supports XML as a content format only, wich is not what I'd be looking for in a REST framework). But whatever the degree of RESTfulness, at least the vendors and open source projects feel the need to claim REST support - this alone seems new and noteworthy to me.

Re: REST is still at a very early stage -- but it is thriving by Chris Norton

The steep learning curve associated with groking REST will limit its adoption for at least the next five years.


Grok REST now, and avoid the last minute rush!

1.) Everything is a resource, and every resource has its own URI. Use URIs to intermediate things like caching and distribution.

2.) Use a small number of fixed verbs; it makes it easy to implement both clients and servers, and it makes it easy to pass around URIs in everything from emails to bumperstickers.

3.) Some methods change the underlying resource and some don't. The ones that don't change things are called 'idempotent' but people will look at you funny if you tell them that, so don't bother. Just know that having methods dedicated to one or the other allows you to optimize your application in useful ways.

4.) Um, that's about it, so you are free to study independently at your desks until the mandatory grok period has transpired.

I wouldn't say "winning" exactly by Erik Johnson

REST is going through an "ah ha!" cycle by those who found that RPC-based services have a shorter half-life than anticipated. I also think people are getting past trying to apply the Fielding dissertation too literally. These are both great things. I agree with Anne that REST is an architectural style, which to me means we'll starting seeing "patterns" emerge. But I also feel like we don't know what other shoe is about to fall. Are there situations in REST that mean borrowing from (gasp) WS-*? Also, I think the big vendors see $$$ in WS-* because they can align IT contract requirements with WS-* specs as named competencies. That's a useful thing to have in your bag whether your like RPC or not.

Crossing the chasm by Stuart Charlton

Good summary article.

I think it's already won on the web, for consumer services. The battle
I think we're still wondering about is "the enterprise" -- using REST
to make business integration more evolvable & productive.

There, I don't think it's winning, necessarily, but I do think it's
almost finished "crossing the chasm". The Atom Publishing Protocol
seems to be the event driving that, but this is also helped by releases
like GData, the Facebook platform, Amazon S3, the Sam Ruby book, etc.

But WS-splat web services continue to flourish unabated in most
enterprises. I think that those looking at WSDL 2.0 and WS-Addressing
are either horrified or enthralled, depending on their value system.
Most still haven't heard of REST, and typically get a quizzical look
when I bring it up in my travels. The reaction is not negative, mind
you, but I think it's indicative of the stage of the journey.

The big adoption will occur when OSS groups & vendors come out with a
new breed of tools that don't just staple a bag labeled "REST" on the
side, but actually provide an agent-oriented platform that's based on
the architecture. All the effort has been too server-focused, in my
view.

We often dream about the leaps in flexibility and evolution over time
due to the constraints of REST, but it hasn't quite made its way into
the agent's development environment. But I don't think even the early
adopters know what this quite would look like. It could be radically
different than what we're used to. And it's a very different direction
from the current rage, BPM-land (tagline, "all your process are belong
to us").

Cheers
Stu

Itempotency by Anne Manes

Chris said:

3.) Some methods change the underlying resource and some don't. The ones that don't change things are called 'idempotent' but people will look at you funny if you tell them that, so don't bother. Just know that having methods dedicated to one or the other allows you to optimize your application in useful ways.


This is not quite right. Methods that don't change the underlying resource are called "safe", and of the four major HTTP methods (GET, PUT, POST, DELETE), only GET is "safe".

Idempotency refers to the repeatable effects of a method. For example, what happens if you execute the same method multiple times. If it always produces the same result, it's idempotent. If the results vary based on what's already been done, then it's not idempotent.

For example, if I PUT a value of 20 to a resource representing the luminosity of a lightbulb, then the value will be 20 regardless of the number of times I execute the PUT method. On the other hand, if I POST +10 to the same resource (indicating "increase luminosity by 10"), then (assuming the original value was 0), the first time I do it, the value will be 10. The second time I do it, the value will be 20. This type of operation is not idempotent. (and also not RESTful, because you're tunneling an RPC [increaseLuminosity] through the POST.)

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

15 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