DotNet Development, SharePoint Customizing, Silverlight, MS Infrastructure and other tips and tricks

Posts Tagged ‘SOA’

How to Create a RESTful Interface?

Posted by PANVEGA on August 11, 2007

REST (representational state transfer) is an approach for getting information content from a Web site by reading a designated Web page that contains an XML (Extensible Markup Language) file that describes and includes the desired content. ” The terms “representational state transfer” and “REST” were introduced in the doctoral dissertation of Roy Fielding one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification.

For example, REST could be used by an online publisher to make syndicated content available. Periodically, the publisher would prepare and activate a Web page that included content and XML statements that described the content. Subscribers would need only to know the URL (Uniform Resource Locator) for the page where the XML file was located, read it with a Web browser, interpret the content data using the XML information, and reformat and use it appropriately (perhaps in some form of online publication).

REST is an “architectural style” that basically exploits the existing technology and protocols of the Web, including HTTP (Hypertext Transfer Protocol) and XML. REST is simpler to use than the well-known SOAP (Simple Object Access Protocol) approach, which requires writing or using a provided server program (to serve data) and a client program (to request data).

SOAP, however, offers potentially more capability. For example, a syndicator that wanted to include up-to-date stock prices to subscribing Web sites might need to use SOAP, which allows a greater amount of program interaction between client and server.

Motivation for REST

The motivation for REST was to capture the characteristics of the Web which made the Web successful. Subsequently these characteristics are being used to guide the evolution of the Web.

REST – An Architectural Style, Not a Standard

REST is not a standard. You will not see the W3C putting out a REST specification. You will not see IBM or Microsoft or Sun selling a REST developer’s toolkit. Why? Because REST is just an architectural style. You can’t bottle up that style. You can only understand it, and design your Web services in that style. (Analogous to the client-server architectural style. There is no client-server standard.) While REST is not a standard, it does use standards:

  • HTTP
  • URL
  • XML/HTML/GIF/JPEG/etc (Resource Representations)
  • text/xml, text/html, image/gif, image/jpeg, etc (MIME Types)

REST Web Services Characteristics

Here are the characteristics of REST:

  • Client-Server: a pull-based interaction style: consuming components pull representations.
  • Stateless: each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.
  • Cache: to improve network efficiency responses must be capable of being labeled as cacheable or non-cacheable.
  • Uniform interface: all resources are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE).
  • Named resources – the system is comprised of resources which are named using a URL.
  • Interconnected resource representations – the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.
  • Layered components – intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.

Principles of REST Web Service Design

1. The key to creating Web Services in a REST network (i.e., the Web) is to identify all of the conceptual entities that you wish to expose as services.

2. Create a URL to each resource. The resources should be nouns, not verbs. For example, do not use this:

Note the verb, getPart. Instead, use a noun:

3. Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.

4. All resources accessible via HTTP GET should be side-effect free. That is, the resource should just return a representation of the resource. Invoking the resource should not result in modifying the resource.

5. No man/woman is an island. Likewise, no representation should be an island. In other words, put hyperlinks within resource representations to enable clients to drill down for more information, and/or to obtain related information.

6. Design to reveal data gradually. Don’t reveal everything in a single response document. Provide hyperlinks to obtain more details.

7. Specify the format of response data using a schema (DTD, W3C Schema, RelaxNG, or Schematron). For those services that require a POST or PUT to it, also provide a schema to specify the format of the response. 8. Describe how your services are to be invoked using either a WSDL document, or simply an HTML document.

For example, Amazon’s web services have both SOAP and REST interfaces, and 85% of the usage is on the REST interface. Compared with other styles of web services, REST is easy to implement and has many highly desirable architectural properties: scalability, performance, security, reliability, and extensibility. Those characteristics fit nicely with the modern business environment, which commands technical solutions just as adoptive and agile as the business itself.

A few short years ago, REST had a much lower profile than XML-RPC, which was much in fashion. Now XML-RPC seems to have less mindshare. People have made significant efforts to RESTize SOAP and WSDL. The question is no longer whether to REST, but instead it’s become how to be the best REST?

The purpose of this article is to summarize some best practices and guidelines for implementing RESTful web services. The REST web services architecture is related to the Service Oriented Architecture. This limits the interface to HTTP with the four well-defined verbs: GET, POST, PUT, and DELETE. REST web services also tend to use XML as the main messaging format.

How to Create a RESTful Interface?

Now we get to the meat of the matter. Instead of covering this from an architectural view, I’ll approach it from a recipe perspective, a series of steps you take and questions you can answer, that will hopefully guide you to creating a great REST interface.

To create a REST service, you need to answer the following questions, and you should answer them in this order:

  1. What are the URIs?
  2. What’s the format?
  3. What methods are supported at each URI?
  4. What status codes could be returned?

In laying out these questions, I didn’t use the proper naming conventions; instead, I used the common names for things that most developers are familiar with. As we answer each question, I’ll also introduce the proper nomenclature.

Question 1: What Are the URIs?

The proper nomenclature would be “What are the resources?” The things identified by URIs are “resources.” That is the terminology used in Roy Fielding’s thesis and also the same terminology used in Architecture of the World Wide Web, First Edition. Resources are identified by URIs.

You might be creating a RPC protocol, or worse, if you only have a single URI that everything goes through. Many years ago, one of the first intranet services I put together was a web interface to an ECO (Engineering Change Order) system. Every time a part was changed, an ECO was filed and had to flow through this system. I created a single script that handled the whole system, a single script that took all it’s parameters via POST. That meant there was no way to bookmark a page in the system; each page had the same URI: /cgi-bin/eco.cgi. Employees wanted to bookmark certain ECOs or send shortcuts via email, but they couldn’t because the URI in the address bar never changed. It was always the same, /cgi-bin/eco.cgi, unchanging, like the blinking 12:00 on an unprogrammed VCR. The employees didn’t know about REST, but what they did know implicitly is that each resource, in this case, an ECO, should have its own URI.

Break your problem down into the types of resources you want to manipulate. The thing to remember is that each resource should have its own URI. Try to list all the resources you could possibly need at this step. Two places to consider when looking for potential resources are collections and search interfaces. A “collection of resources” may, in itself, be a whole new resource.

A search interface is another source of resources. You enter criteria for the resources you want to find, and a list of matching resources are returned. You may notice, though, that the results of a search are just a collection of resources, ones that match a particular criteria, and as such, this is really just a narrower version of the first case of a resource collection.

Consider a very simple example of a system for maintaining an employee contact list. For our example, it will contain each employees name, title, and contact information. In such a system, each user should have their own URI with an appropriate representation. That representation should contain the name, title, and contact information for that employee.

There is also a collection of resources that is, in itself, another resource. The collection of all employees is another resource in our system. So we have identified two kinds of resources in this tiny system, and so there will be two types of URIs:

  1. Employee (One URI per employee)
  2. All Employees

After you’ve identified the resources via their URIs, it’s time to consider the next question.

Question 2: What’s the Format?

The proper terminology here is “representation.” You can’t actually reach out and touch the resources behind the URIs you identified in Step 1. What you can do is exchange representations of those resources. When I do a GET on an “employee” resource, I need to get something back which conveys information about that employee. These days HTML, XML, images, sound, and movies are all potential formats that could be used. For now, we’ll restrict ourselves to using XML: it’s a pretty popular format, lots of tools are available to process it, and there is an expectation that when you say “web services,” you are referring primarily to the exchange of XML documents. And, yeah, this is being published on!

For each of the resources you listed in Step 1, you need to decide what the representations are going to look like. If possible, reuse existing formats if they are applicable. This can increase the chances that your system can be composed with other systems.

In our example employee contact list above, we could have the following representations:

Employee Format
For the sake of exposition, I will make up a new XML format for this information. Exposition–“A statement or rhetorical discourse intended to give information about or an explanation of difficult material”–which just means that I get to cheat as long as you learn something in the process.
<employee xmlns=''>
    <name>Full name goes here.</name>
    <title>Persons title goes here.</title>
    <phone-number>Phone number goes here.</phone-number>
Employee List Format
Since each employee will have his or her own URI with all the details there, our list will only include that URI.
<employee-list xmlns=''>
    <employee-ref href="URI of the first employee"/>
	 Full name of the first employee goes here.</employee>
    <employee-ref href="URI of employee #2"/>Full name</employee>
    <employee-ref href="URI of employee #N"/>Full name</employee>

Note that we haven’t mapped the representations to resources just yet. To do that, we need to consider the methods.

Question 3: What Methods Are Supported at Each URI?

In the proper nomenclature, how do the URIs we defined in Step 1 get dereferenced?

Agents may use a URI to access the referenced resource; this is called dereferencing the URI. Access may take many forms, including retrieving a representation of the resource (for instance, by using HTTP GET or HEAD), adding or modifying a representation of the resource (for instance, by using HTTP POST or PUT, which in some cases may change the actual state of the resource if the submitted representations are interpreted as instructions to that end), and deleting some or all representations of the resource (for instance, by using HTTP DELETE, which in some cases may result in the deletion of the resource itself).

We’ll restrict the discussion to accessing resources using one the four basic HTTP methods that can be applied to a URI: GET, POST, PUT, and DELETE. HEAD is really a GET without a response body, and there are also others defined by RFC 2616 like OPTIONS. In addition, specs like WebDAV introduce even more methods. That’s nice, but you should be able to go very far with just the four basic methods, which align nicely with CRUD, an acronym from the database world which stands for Create, Retrieve, Update, and Delete.

HTTP Method CRUD Action Description
POST CREATE Create a new resource
GET RETRIEVE Retrieve a representation of a resource
PUT UPDATE Update a resource
DELETE DELETE Delete a resource

I hesitated to include this table. By presenting it, I wanted to point out the overlap in the four basic methods of HTTP. What I don’t want to happen is that you start thinking of web resources as SQL tables. Don’t do that.

Make sure your GETs are side-effect free. This is a biggie, the one where many services get it wrong. GETs must be both safe and idempotent. In turn, anything which does not have side effects should use GET.

So if you want to create a new resource, use POST. Want to retrieve a representation of a resource? Use GET. To update a current resource, use PUT. Finally, to delete a resource, use DELETE.

Once you have decided on the URIs (Step 1), picked representations (Step 2), and decided on methods (Step 3), you need to match them all up. At the very least, you’ll need to pick a representation for the response of every GET and a representation to place in the request for PUT and POST. Optionally, you may want to consider the representation, if any is returned from a POST.

Let’s go back to our employee contact list, and now we can match up the resources, the representations, and the methods.

Resource Method Representation
Employee GET Employee Format
Employee PUT Employee Format
Employee DELETE N/A
All Employees GET Employee List Format
All Employees POST Employee Format

Question 4: What Status Codes Could Be Returned?

Not only do you need to know what type of representation is returned, you also need to enumerate the typical HTTP status codes that could be returned. In a perfect world, this step wouldn’t be necessary since a good implementation would handle every status code correctly. In practice, you should list all the status codes you expect to return. This will provide good guidance for implementers on the conditions they should be testing for.

We’ll update our table for our employee contact list to include the expected status codes

Resource Method Representation Status Codes
Employee GET Employee Format 200, 301, 410
Employee PUT Employee Format 200, 301, 400, 410
Employee DELETE N/A 200, 204
All Employees GET Employee List Format 200, 301
All Employees POST Employee Format 201, 400

One often hears the criticism that HTTP is synchronous, while many services need to be asynchronous. It is actually quite easy to implement an asynchronous REST service. An asynchronous service needs to perform the following:

  1. Return a receipt immediately upon receiving a request.
  2. Validate the request.
  3. If the request if valid, the service must act on the request as soon as possible. It must report an error if the service cannot process the request after a period of time defined in the service contract.

More References:


Posted in REST, SOAP, WebServices | Tagged: , , , , | Leave a Comment »