How Does REST Differ from SOAP and RPC?

SOAP and Remote Procedure Call (RPC) are the other two architecture patterns available to implement services. In this lesson, we’ll look at how REST differs from them.

REST vs. SOAP-based services

There is a vast amount of difference between SOAP-based services and REST. The major differences can be described using the following points:

• Transport protocol
• Based on RPC
• Standards
• Persistence of state
• Uniform resource

Following are the details:

• Transport protocol: REST is dependent on one transport protocol which is HTTP. SOAP-based services can be used with a variety of transport protocols.

• Based on RPC: SOAP itself is RPC-based. So, each service will have its own methods and interfaces. Due to this, the toolkits and clients of SOAP have a difficult task in creating generic interfaces that can be used in multiple places. REST isn’t based on RPC and, therefore, can make use of generic interfaces.

• Standards: REST uses the existing web standards. It doesn’t have its own standards. This makes it easier to create services, as a different set of libraries and toolkits isn’t required. SOAP-based services have their own standards, including Web Services Description Language (WSDL), SOAP, and Universal Description, Discovery, and Integration (UDDI). So, to create a service using SOAP, we’ll require a minimum set of libraries to parse WSDL, understand SOAP, and register itself with UDDI.

• Persistence of state: REST is stateless. The server doesn’t keep track of changes in state. So, no handling will be available on the server side. In contrast, SOAP-based services can handle sessions.

• Uniform resource: In REST, access to each resource and methods to access the operations supported by it must be uniform across all resources. For example, each resource is addressable using a URI. There’s no intermediary that maps the resource to the URI. In SOAP-based services, uniformity of access to the resources and methods of the operations supported by the resource can vary from resource to resource.

The main points that make REST and SOAP different are the second and fourth points.

The points described above aren’t meant to declare which of them is better but rather to bring out the differences between the two types of web services that are currently most common.

REST vs. RPC-based services

Remote Procedure Call (RPC), simply put, is a protocol that allows a program running on a system to ask another system to execute a particular program and retrieve the result. The main differences between REST and RPC can be understood based on the following points:

• Verbs
• Payload type
• Modeling
• Actions

When deciding whether to use REST or RPC, verbs and actions become the deciding factors. Let’s look at the details:

• Verbs: Verbs or HTTP methods are used by both REST as well as RPC. The major difference is that in REST we can use all of the verbs (GET, POST, PUT, PATCH, DELETE, and OPTIONS), but with RPC only GET and POST are used primarily. The other verbs don’t make sense for RPC, as what needs to be done becomes part of the payload. In REST, all the verbs contribute to what needs to be done.

• Payload type: In REST, a payload type can be any standard Multipurpose Internet Mail Extensions (MIME) type, with XML and JSON being the most common. The type of payload in RPC is determined by the type of RPC, i.e., JSON, XML, or binary. So, JSON-RPC has JSON as the payload, and XML-RPC has XML as the payload. Custom RPC systems such as Apache Thrift have binary payloads.

• Modeling: Modeling involves the verbs, the payload, and the actions. Modeling in REST has to take care of what verb is most suited for the payload as well as the action. If the action is a partial update, the verb will be PATCH, and the payload can be XML, JSON, or any of the standard or custom MIME types. However, if we’re using RPC, the verb can only be POST, as the payload will have the details that the action is a partial update. Hence, for RPC modeling, the payload itself will provide the data for the service and the action to be performed.

• Action: In simple terms, the action represents what needs to be done. The action can be a simple CRUD operation or a complicated operation that might involve calling other operations, leading to a chain of operations. In the world of REST, each operation is self-contained or, at the very least, will direct a client to the endpoint that is to be called next in the sequence. So, each verb, URI, and payload combination specifies one action. We can create an endpoint that acts as a starting point for a chain of operations without directing the client to the next endpoint, but that’ll go against the principles of REST. However, with RPC, this won’t be an issue. In RPC, the payload itself will contain the action and data required for the action. The action will be part of the payload, and RPC doesn’t care much if the operation, in turn, calls another operation. Hence, chaining without informing the client is allowed in RPC.

Note: The purpose of the above points isn’t to declare which is better, but only to help users make informed choices. Based on individual requirements, SOAP or JSON-RPC may be better than REST. And that’s fine. Always remember, never shoehorn a technology or an architectural principle just because it’s in vogue.