The concept behind Web services is a revolutionarily simple one: Create services that can easily communicate with one another in a standard way, and can be easily reused. Initially, those services were created as simply as possible and with as little overhead as possible.
The reality has turned out to be different. A complex architecture, including SOAP, Universal Description Discovery and Integration (UDDI), and Web Services Description Language (WSDL), among others, has sprung up around Web services, with new standards and protocols being released all the time. The constant standards wars are making matters more complicated.
As a result, there's a movement afoot to dramatically simplify the building of Web services, a kind of return-to-the-roots phenomenon. Some people like to say that this new movement is interested in building Web services with a small "w" -- in other words, build services that can exchange information, but without the high overhead associated with the current Web services stack.
In this first part of a two-part column, I'll look at the potential benefits of creating Web services without the associated Web services stack. In part two, I'll take a closer look at the technology and at someone who has developed a unique, creative Web service.
Is simpler better?
Why is there a backlash against the way Web services are currently built? Stephen O'Grady, an analyst with RedMonk, said: "There are political issues involved in Web services standards, where you have different vendors backing competing standards. In addition to that, there are a large number of standards that have sprung up that are very opaque to a large number of developers. You also have developers saying that there's no need for the complexity and overhead involved."
In short, he said, the current state of Web services means that many developers are locked out of developing applications because they lack the knowledge. It also means that Web services development is unnecessarily complex, slow and laborious -- and hamstrung because of political squabbles and a growing set of hard-to-understand standards and protocols.
Because of these problems, an increasing number of developers are turning to a much-simplified way of developing Web services, known as Representational State Transfer (REST). I'll cover REST in more detail in my next column, but here's the brief rundown. With REST, you build services using XML, but rather than communicating via SOAP and using the rest of the Web services stack, you use the much simpler HTTP. Simplicity is the key to REST; services can be built using basic commands such as "put," "get," "post" and "delete."
Lightweight Web services are already being widely deployed on the Web this way, notably in the flickr.com photo-sharing site, and the http://del.icio.us/ "social bookmarking" site that lets people share their collections of links with other. It has also been used to develop the Amazon Light service that allows fast Amazon searching, as well as automatically searching related sites simultaneously. (I'll interview the developer of Amazon Light in my next column.) The Amazon Light service was built using Amazon's public Web services feature that allows anyone to build a Web service on top of Amazon.
Developers have so far been enthusiastic about building lightweight Web services. And they have been voting the way they know best -- by using the technology they favor. O'Grady said Amazon Web services are available using the traditional way of delivering Web services, via SOAP, and in the simplified way, by using HTTP. Developers, he said, favor HTTP over SOAP by an 80% to 20% margin.
Paying off in the enterprise
It's not only in the consumer space that simplified Web services may pay off. It's inside corporations as well. Only a limited number of developers have a sophisticated understanding of the Web services stack, and have learned the toolsets necessary to building Web services using that stack. That cuts down on the ability of enterprises to use Web services, or requires that they spend a good deal of time and money retraining their developers or hiring new ones.
But "any developer who has worked on networked applications can easily work with REST," O'Grady said. That means saving time and money and bringing the applications to market faster.
However, O'Grady said there is still a place for traditional Web services inside enterprises -- a major one. REST-based Web services aren't suited if a company needs reliability, security and absolute interoperability. And in many cases, enterprises require security and reliability. That means that lightweight Web services will find a much more limited use inside enterprises than in consumer-level services, such as the www.flickr.com site. But when enterprises want to build similar consumer sites, or when they can get by with similar lightweight requirements, then REST may be the answer.
What's it like to build a lightweight Web service and how does REST work? I'll take a closer look in my next column, where I interview someone who has built a public Web service using REST.
Continues in Part Two
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.
