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.
<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.
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.
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.
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.
A detailed introduction to REST is Richardson and Ruby's book Restful Web Services (O'Reilly Media, Inc., May 2007).
Some of the preceding material is from Enterprise Web 2.0 with EGL (MC Press, 2009; http://www.mc-store.com/5107.html).