If you have followed the latest advancements in the technologies and standards around web services, you must have come across the term “REST” at least more than once.
In rough terms REST is a way of building web services by relying exclusively on the infrastructure of the World Wide Web to define operations and exchange messages. This is an alternative to “traditional” web services, which instead use a set of standardized XML dialects, WSDL and SOAP to achieve the same goals.
The reason I’m writing about REST is that if you, like me, have prematurely judged it as some kind of toy technology, you are in for a real eye-opener!
First of all, let’s be clear about the origin of REST. As a term it means Representational State Transfer, as a concept it stands completely separate from web services.
It was first defined in the year 2000 by a PhD student at the University of California by the name Roy Fielding. Fielding, in his doctoral dissertation entitled Architectural Styles and the Design of Network-based Software Architectures, sought to define the architectural principles that make up the infrastructure of the most successful large-scale distributed system created by mankind: the World Wide Web.
Fielding thought that by studying the Web, he would be able to identify some key design principles that would be beneficial to any kind of distributed application with similar needs of scalability and efficiency. He referred to the result of his research as “REST”.
So, what is REST?
REST is an architectural style for building distributed systems.
The key design principle of a REST-based architecture is that its components use a uniform interface to exchange data.
Uniform interface means that all components expose the same set of operations to interact with one another. In this interface data is referred to as resources and contains three main concepts:
- A naming scheme for globally identifying resources
- A set of operations to manipulate resources
- A format to represent resources
The idea is that generalizing and standardizing the components interface reduces the overall system complexity by making it easier to identify the interactions among different parts of the system.
As of today, the Web is the only system that fully embraces the principle of unified interfaces, and it does it in the following way:
- URI is used as a naming scheme for globally identifying resources
- HTTP verbs define the available operations to manipulate resources
- HTML is the textual format used to represent resources
Applying REST to web services
Now, it is a known fact that the Web was created in order to provide a worldwide network for distributing static documents. However, it has been proven that the Web holds a potential that goes far beyond its original goal. Imagine if we could leverage the REST infrastructure of the Web to build web services. Wouldn’t that be cool?
First of all, let’s take a look at what web services are used for:
- Define a set of operations to manipulate resources
- Uniquely identify these operations so that they can be globally accessed by clients
- Use a common format to represent the resources exchanged between web services and their consumers
Well, the Web seems to have the entire infrastructure we need to accomplish all of those goals already in place. In fact the HTTP protocol defines a pretty rich interface to manipulate data. Moreover this interface maps surprisingly well to the kind of operations usually exposed by web services.
|HTTP verbs||Web Service operations|
Also, web services contracts are inherently accessed through URLs, it isn’t too much of a stretch to use URLs to access single operations in a contract.
Finally, web services encode the contents of their messages using SOAP, which is a XML dialect. But why do we need a whole new protocol to represent resources, when we could simply use XML as is instead?
What we just did, was applying the design principles dictated by REST to web services. The result of this process is commonly referred to as “RESTful” web services.
This is how REST web services compare to traditional ones:
|Goal of web services||Traditional||REST|
|Identifying resources and operations||SOAP||URL|
As you can see, REST web services leverage the stability, scalability and reach offered by the same technologies and standards that power the Web today. What’s most fascinating with REST is the huge potential that comes out such a simple design.
However, don’t think even for a moment that REST will ever replace SOAP-based web services. Both architectures have their strengths and weaknesses, and REST is certainly not the right answer for all kinds of applications. I am especially thinking about corporate environments, where the needs for security and reliability are better addressed by the standards incorporated in WSDL and SOAP.
As always, the solution lies in using the right tool for the job.
Windows Azure is an application hosting infrastructure service where customers can have their software running without having to worry about the costs of deploying as well as maintaining server and network hardware. Microsoft offers 24/7 hosting based on virtual servers in a configuration that can easily be adapted to scale up depending on the customer’s needs.
This is cloud computing in a nutshell. Software will no longer run exclusively on a client machine or inside the fences of a corporate intranet, but will be able to take advantage of the functionality offered by ubiquitous services that live on the Internet, a.k.a. “the cloud”
Windows Azure is the software and hardware platform provided by Microsoft to create a cloud where customers can deploy applications that will available through the Internet. Right now Windows Azure supports applications built on top of the .NET Framework, SharePoint, or Dynamics CMS. Moreover the platform offers permanent storage with SQL Server and a series of centralized information sharing and synchronization services that go under the name Live Services.
Microsoft is proving the value of Windows Azure by betting on its own platform, and will soon start to give customers the option to buy server installations of their products on the cloud. This means that customers will be able to have a Microsoft server product up and running really quickly by delegating configuration and maintenance to Microsoft, all of this for the price of a subscription. This concept is called Microsoft Online Services, and it the current offering are included Exchange, Office Live, SharePoint, and Microsoft Dynamics CMS.
This is the first of the big announcements made here at PDC 2008 in Los Angeles, USA. Today they will give the first public preview of the next version of Windows, code-named Windows 7. Stay tuned!