Rest-based Web services: Basics

Basis

REST defines a set of architectural principles that you can use to design system-centric WEB services, including how clients written in different languages can process and transfer resource state over HTTP. If you consider the number of Web services that you use, REST has become the main Web service design model in recent years. In fact, REST has a very large impact on the Web and, because of its ease of use, has generally replaced the design of interfaces based on SOAP and WSDL.

REST This concept was in 2000 by Roy Fielding at the University of California, Irvine, during an academic paper "Architectural Styles and the design of network-based Software Architect Ures "For the first time, his paper analyzes a series of software architecture principles that use WEB services as a distributed computing platform, and the REST concept presented here is not getting much attention." Many years later, the main framework for REST has begun to emerge, but it is still being developed, as it has been widely accepted in various platforms, such as JSR-311, as an integral part of java™6.

This article argues that for the most pure form of REST Web services that are attracting so much attention today, the implementation should follow four basic design principles:

Use an HTTP method explicitly.

No state.

Exposes the URI of the directory structure.

Transfer XML, JavaScript Object notation (JSON), or both.

The following sections detail these four principles and provide a technical rationale for why these principles are important to REST Web service designers.

Using an HTTP method explicitly

One of the main features of the REST-based WEB Services is the explicit use of HTTP methods in a manner consistent with the protocol defined in RFC 2616. For example, an HTTP get is defined as a data generation method designed to be used by a client application to retrieve resources to fetch data from a WEB server, or to execute a query and expect the WEB server to find a matching set of resources and then use that resource for a response.

REST requires developers to use the HTTP method explicitly and in a way that is consistent with the protocol definition. This basic REST design principle establishes a one-to-one mapping between the Create, read, update, and Delete,crud operations and HTTP methods. Based on this mapping:

To create a resource on the server, you should use the POST method.

To retrieve a resource, you should use the Get method.

To change the state of a resource or update it, you should use the Put method.

To delete a resource, you should use the Delete method.

A regrettable design flaw inherent in many Web APIs is the use of HTTP methods for unintended purposes. For example, the request URI in an HTTP GET request typically identifies a specific resource. Alternatively, the query string in the request URI includes a set of parameters that define the search criteria that the server uses to find a matching set of resources. At the very least, the http/1.1 RFC describes the Get method. However, in many cases, an inelegant Web API uses HTTP get to trigger transactional operations on the server-for example, adding records to a database. In these cases, the GET request URI is either improperly used, or at least not in a restful manner. If the Web API uses get to invoke a remote procedure, it should resemble the following:

Get/adduser?name=robert http/1.1

This is not a very elegant design because the Web method above supports state change operations through HTTP get. In other words, the HTTP GET request has side effects. If the processing succeeds, the result of the request is to add a new user to the underlying data store--in this case, Robert. The problem here is mainly semantic. The WEB server is designed to respond to HTTP get requests instead of adding records to the database by retrieving the resources that match the path (or query condition) in the request URI and returning those resources or their representations in the response. It is inconsistent to use get in this way from the perspective of the intended use of the Protocol method, and then from the perspective of a http/1.1-compliant Web server.