A RESTful approach to Web services

Before choosing SOAP for your extended enterprise's Web services, consider Representational State Transfer.

Is Web services development too complicated? A small but influential group of Web developers thinks so. These developers advocate a new approach - one they say is simpler than the World Wide Web Consortium's Simple Object Access Protocol-based model favored by application development tool makers such as BEA Systems, IBM and Microsoft. This new architectural approach, called Representational State Transfer (REST), also results in more scalable code, they say.

Among the more noteworthy REST backers are Roy Fielding, chair of the Apache Foundation; and Sam Ruby, a senior developer and Web services guru at IBM (although IBM itself does not support REST). And developers at Web powerhouses Amazon and Google have experimented with REST to create interfaces to their popular Web services. Recently Thomson Publishing Asia Pacific used REST to create a Web-based typesetting service for its legal publishing group in Sydney, Australia.

REST at work

REST relies on a single application protocol (HTTP), universal resource indicators (URI) and standardized data formats, through XML. It employs established HTTP methods such as GET and POST to direct applications. So instead of creating a standard, machine-readable way for applications to discover and use application components on remote systems - the way SOAP is being used for Web services - REST developers use URIs to create a common ground so applications can use HTTP and XML to share data. REST developers use XML documents rather than application-method calls to tell distributed programs how to use each other's data.

REST proponents say that using the SOAP protocol to access the functions of remote programs directly is doomed to suffer from the same type of interoperability problems that hobbled previous distributed computing architectures such as DCOM and Common Object Request Broker Architecture.

Security problems also will plaque SOAP, says Mark Baker, an independent Web architecture consultant and one of the maintainers of a REST resource site for developers. Because firewalls do not understand the meaning of SOAP-based Web services messages, they will never let those messages pass, he says.

REST messages don't have this problem, Baker says, because they only use operations specified in the HTTP standard - operations that are well-understood by firewall applications and administrators. (Vendors, of course, are addressing the SOAP issue by developing Web services security standards and products, just as they developed firewalls and security standards for HTTP.)

REST the best

Before deciding to use REST for its Web-based typesetting service, Thomson Publishing considered SOAP. Developers chose REST to write a wrapper around the company's typesetting software because it offered superior performance, reliability and scalability to SOAP, says Hao He, a Web architect with the company.

Using the wrapper - called the Generic Typesetting System (GTS) - Thomson can now more easily typeset documents from different data sources, be they legislative bodies, courts or government agencies. "Before using this technology, we'd have to write a specific solution for each new data source," He says. "Now we are able to rapidly create RESTful Web services that reflect typesetting workflow specific to Thomson."

REST's document-centric approach made it particularly appropriate for Thomson. With every new typesetting job, the user creates XML documents, and the GTS handles the rest: feeding the XML documents into Thomson's proprietary typesetting system as it becomes available. "Although the system can only handle one process at a time, the user can send any number of requests," He says. "The GTS handles resource management tasks, such as job priority and load balancing, separately and makes the overall system efficient."

A real sleeper

As positive as early REST user experiences have been, a lack of tools is a big obstacle to widespread adoption, critics say. As yet, no big application development vendors have committed to REST, although they do seem to be taking it seriously. REST has "some very important characteristics that we are examining," says David Orchard, technical director at BEA.

Still, commitment from the tool makers might be necessary before REST makes any inroads. Products such as Microsoft's Visual Studio .Net or IBM's WebSphere, automatically produce SOAP-based Web services.

"From a product perspective, REST is almost invisible," says Ronald Schmeltzer, a senior analyst with Zap Think. "If the REST people want to have their day, they're going to have to get it into the tools that create or consume Web services."

Baker disagrees. He says virtually any HTTP-compliant tool could be used to develop REST Web services. "There are a whole lot of REST tool kits available, it's just that people don't know what they are," he says.

The same tools that create Java servlets could be used to build REST-based Web services, Baker says. "They follow the HTTP specification, and by following it, they implicitly are following the constraints of the REST style," he says.

BEA's Orchard suggests that REST might one day co-exist with SOAP as developers seek out multiple techniques for Web services styles. "Sometimes there is more than one way to skin a cat," he says.

McMillan is a freelance writer in San Francisco. He can be reached at bob@filbert.net.