first wrote an XML-over-HTTP web service almost a decade ago. At that time, it seemed a completely natural solution to a practical business problem: provisioning web-based, product-pricing quotes. As web services became a formal technology with numerous standards, I became somewhat weary of the true usefulness of the technology. It grew so complex and institutionalized that it carried a significant learning curve and required considerable investment in the infrastructure. I often wondered what happened to my primitive XML-over-HTTP/S services, and why they were not good solutions anymore. They worked perfectly well for my application—a major e-business site serving a great number of diverse businesses across the globe.

Then two years ago I had a revelation: my good, old style of web services design was back and it now had a formal name—REST (Representational State Transfer). It was documented in the doctoral work of Roy Fielding, primary architect of HTTP 1.1 and co-founder of the Apache HTTP server project. Since then, I have effectively adopted REST as my architectural style for web services, and I have successfully applied it on multiple occasions.

This article demonstrates the most essential features of RESTful web services through a sample shipment-tracking application implemented in Java. Hopefully, it will pique your interest in this very common-sense architectural style.

Key Properties of the REST Architectural Style
REST is not a standard like SOAP or a protocol like HTTP—for that matter, it is not necessarily a services-oriented protocol either. Rather, it is a set of extraordinarily simple recommendations on how to leverage Internet protocols, formats, and infrastructure to accomplish technically sound and well-defined interoperable architectures. Although REST (like SOAP) is often associated with XML, XML is not a premise of REST and following the REST style does not automatically mean using XML. REST is primarily an architectural style, and as such it is far more concerned with the proper and complete utilization of web infrastructure and protocols than with the specifics of the exact formatting for the resource state representation.

REST's focus is really on web resources, related operations, and the transfers of their state representation to the clients. These web resources have representational states that are created, accessed, updated, and deleted via standard methods of the HTTP protocol: PUT to create, GET to read, POST to update, and DELETE to delete. (Think of RESTful services as CRUD (Create, Read, Update, Delete) operations upon web resources.)

In addition, probably the most attractive fact about the REST architectural style is that it fully leverages the most common and readily available parameters and methods of the HTTP protocol, such as HTTP methods, headers, representations, types, and caches. For that reason, REST architectural style has been recently included in the concept of WOA (web-oriented architecture), as it truly represents the architectural style of the mechanism that operates underneath the web as we know it.