Architectural styles in Web services

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

Web services traditionally fulfill the RPC style. You use a business-specific operation name—for example, 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, 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. In most cases, 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 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 fulfill two purposes: to specify the service location, and to allow for runtime validation of the SOAP message

One benefit of the traditional technology is that you can do as follows to cause the requester to access the same-named service at a different location: update the WSDL file that is used by the requester at run time. 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 IBM® Rational® EGL Community Edition, a REST service is one that 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 doesn't refer to a Web page, but to information about an employee, as indicated by the second qualifier; and, in particular, about a specific employee (number 123), as indicated by the third qualifier.

Both Web sites and REST services are associated with many addresses. In the case of a Web site, an address provides access to a Web page. In the case of 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; and 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. To allow for flexibility over time, EGL provides a way to quickly update the service locations accessed by a requester. The update requires the requester's redeployment. However, the details of operation name and service interface are simpler, and complex administrative files are not required.

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 this topic distinguishes between REST and SOAP services, the real distinction is between the RPC and RESTful styles.

REST-RPC services

The industry provides many kinds of REST-RPC services. EGL REST services are the type of REST-RPC service that is written in EGL.

You use an RPC style to access an EGL REST service. Parameters and a return value identify the data to exchange, and you can think in terms of a business-specific operation name such as GetEmployeeData. The request message always uses an HTTP POST method, but that detail is not visible to you.

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 used with a Web service and is sometimes the basis for messages exchanged with a REST service
  • XML Schema, which is information—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).


Feedback