Continued from Part One
Some say that Web services have become an unnecessarily complicated technology, beyond the reach of many developers. They said a kind of "back-to-the-roots" movement is needed, in which Web services can be built with a small "w." In other words, services that can exchange information, but without the high overhead associated with the current Web services stack and the complexity of competing standards.
In this second part of a two-part column, I'll take a look at the simplified way of delivering Web services known as REST (Representational State Transfer), examine how one developer has used Web services and REST, and determine when to use traditional Web services.
A look at REST
REST's underlying philosophy is very much like the initial guiding principles of Web services. It can be used to connect disparate services over the Internet or a network using XML. So the idea behind it is to easily allow applications and services to communicate with one another.
But while the basic idea is the same, implementation is quite different. REST doesn't use the now-traditional Web services stack of SOAP, WSDL, UDDI and all the other protocols. That's because the key to REST is simplicity and low overhead. Services can be built using HTTP and basic commands such as PUT, GET, POST and DELETE.
This low overhead is both REST's strength and weakness. The low overhead means that it's easy to build a service, and it can be done quickly and cheaply. So it's ideally suited for building public services such as the photo-sharing site, www.flickr.com, and the social bookmarking site, del.icio.us
But the low overhead also means that REST doesn't include built-in security and reliability, so it's not well-suited for enterprise use, particularly between business partners or for e-commerce.
A developer's view of REST
The best way to learn about REST's benefits is straight from the horse's mouth -- from the developers themselves. A perfect example of how REST can be used is the at Amazon Light site. It's a remarkable site in that it includes the services of multiple Web sites -- Amazon, the del.icio.us bookmarking site, Google's Gmail site, the the bloggers blogging site, and the Dropcash site, which allows anyone to easily create a fund-raising campaign. And you can also use a variety of Amazon services, such as adding an item to your Amazon Wish List.
For example, say you're viewing a product on Amazon. From Amazon Lite, you can create a del.icio.us at the del.icio.us site, create a blog entry about it at blogger, create a Dropcash fund-raising campaign with it, and so on.
Amazon Lite is the brainchild of Alan Taylor. He said he turned to using REST because of the increasing complexity of Web services, which got in the way of development.
"I had been doing lightweight Web development for about five years, and then things rapidly became more and more complicated," he said. "I began to wonder what it was I was trying to accomplish; it seemed as if everything I was doing was just massaging strings."
Taylor sees his job as a developer as presenting information from a variety of databases, and when he took a step back from his work, he saw that data could be accessed in many different places.
"I thought, 'This is so cool, I can make it any way I want,'" he recalled. But he came up against the limits of having to use SOAP, UDDI and the rest of the Web services stack.
Instead, he turned to REST, and hasn't looked back since.
"The key to REST for me is simplicity," he said. "It's the same reason that I picked up HTML. REST may be a little bit sloppy, but you can see exactly what you're doing in REST, you don't have to rely on any clients and you can see exactly what you're getting."
For his Amazon Lite site, Taylor chose several key pieces of data from the Amazon database. REST fetches data from a variety of other places that enhances the experience of using Amazon by adding new features and content. For example, when you view a book, you'll also see author-related links and news, via Google. When you view a movie, there are links to information about the movie at sites such as the Internet Movie Database. And on all pages, there are links to the services of del.icio.us, blogger, Dropcash and Gmail, as well as Amazon.
Ultimately, REST gave Taylor full control over development.
"For me, using Web services was getting lost in a blizzard of white papers, and felt like I didn't know what I was doing. Using REST puts me in control and makes it much easier to build what I want."
The wrap-up
Ronald Schmelzer, senior analyst with ZapThink, warns that people should not expect REST to be used for all purposes.
"You have to balance when to use REST and when to use Web services," he said. For simple ad hoc development, even within a corporation, REST is useful because of how quick and easy development is. But for secure, reliable services that need to be managed, he said, companies will be better off using the full Web services stack.
It's likely that REST is here to stay. Expect to see more consumer sites built using it, and it will be used in the enterprise as well, at least when an enterprise doesn't need security or reliability. In the long run, both REST and Web services will live inside the enterprise as well as outside of it. Most likely, both will become standard part of companies' service-oriented architectures.
FOR MORE INFORMATION:
Expert Mark Baker answers your REST questions.
About the Author
Preston Gralla is an expert on Web services and is the author of more than 20 books, including How the Internet Works. He can be reached at preston@gralla.com.
