Architectural styles in web services

A web service can represent a Remote Procedure Call (RPC), a document-oriented style that is associated with Representational State Transfer (REST), or a hybrid style called REST-RPC.

Web services traditionally fulfill the RPC style. You use a business-specific operation name, such as UpdateEmployeeData, and a set of arguments, as if you are invoking a function. In many cases, you expect a return value.

The RESTful style is based on the transfer of a single unit of business data at most. The service implementation can do whatever is necessary, but the operation name is generic. For example, the operation name might be GET or UPDATE.

The RESTful style hides detail. For instance, an employee record is said to be handled in only one of a few ways, regardless of what is done with the data. A business-specific operation name such as UpdateEmployeeData is not meaningful in determining what operation to perform.

REST-RPC services use business-specific operation names. Usually, these services use an RPC style of data exchange, but do not use the complex administrative files that are needed to handle traditional web services.

RPC-style SOAP services

A traditional web service receives and returns data in SOAP format. The SOAP envelope is the primary content of the HTTP entity-body:

<Envelope>
   <Header>
      <!-- SOAP Headers here, for QoS -->
   </Header>
   <Body>
      <!-- Business data -->
   </Body>
</Envelope>

The SOAP message is not complex. The headers provide the main benefit of SOAP, allowing for support of security and of service coordination. The body holds the data that is used by the service implementation during a service request or by the requester during a service response.

In the traditional web service, the content of the SOAP envelope is related to the content of Web Services Description Language (WSDL) files, which are complex. Those files are used at the following times:

At service design time, to communicate the service interface to developers and other designers
At the time of developing the requester, to aid the process by which the developer defines the data that will be exchanged with the service
At run time, to specify the service location and to allow for runtime validation of the SOAP message

With the traditional technology, you can update the WSDL file that is used by the requester at run time in order to cause the requester to access the same-named service at a different location. In this way, you can respond quickly to technical change, as might accompany a merger.

Developers and deployers use automated tools to work with the WSDL file.

REST services

In some contexts, a REST service uses web facilities to fulfill the RESTful style. In the RESTful style, you transfer a single unit of business data (if any) and use a narrow set of operation names. In addition, the service address includes information about the data being operated on. For example, consider the following address, which is composed of three qualifiers:

www.example.com/employee/123

The address does not refer to a web page, but to information about an employee, as indicated by the second qualifier. In particular, the address refers to information about a specific employee (number 123), as indicated by the third qualifier.

Both websites and REST services are associated with many addresses. For a website, an address provides access to a web page. For a REST service, an address provides access to a unit of business data.

A REST service provides at least one of the following four operations:

GET, for reading data
POST, for creating data
PUT, for updating data
DELETE, for deleting data

These operations correspond to the major HTTP methods that can be specified in the HTTP request message.

REST services generally do not involve WSDL definitions.

When an HTTP message is used for a REST service, the entity-body often holds business data in the form of Extensible Markup Language (XML) or JavaScript Object Notation (JSON). In most cases, a SOAP envelope is not present.

Some authors anticipate a greater use of the SOAP envelope for data exchange with REST services, or at least a greater use of SOAP (or HTTP) headers so that the SOA runtime software can better handle QoS issues.

Although the information in this topic distinguishes between REST and SOAP services, the real distinction is between the RPC and RESTful styles. For additional details about REST, see “REST for the developer.”

Sources of additional information

A detailed introduction to REST is Richardson and Ruby's book Restful Web Services (O'Reilly Media, Inc., May 2007).

For an overview of service interaction and some of the RPC-related technologies, see SOA for the Business Developer by Margolis and Sharpe (MC Press, May 2007). That text also gives an overview of the following areas:

Extensible Markup Language (XML), which is the basis of the SOAP format that is used with a web service and is sometimes the basis for messages exchanged with a REST service
XML Schema, which is essentially a code that is used to validate XML

Notice

Some of the preceding material is from Enterprise Web 2.0 with EGL (MC Press, 2009; http://www.mc-store.com/5107.html).