In general, an architectural style is a large-scale, predefined solution structure. Using an architectural styles helps us to build the system quicker than building everything from scratch. Architectural styles are similar to patterns, but provide a solution for a larger challenge.

In this blog we study several architectural styles for communication in distributed systems. The REST style (Representational State Transfer), the HATEOAS style (Hypermedia As The Engine Of Application State), the RPC style (Remote Procedure Call) and the SOAP style. We compare the approaches, show advantages and disadvantages, commonalities and differences.

APIs can basically be realized using any of these styles. How do we know, whether a particular architectural style is appropriate for a given API? The resulting API exposes many of the previously stated desirable properties.

Most commonly, APIs are realized using REST over HTTP. This is why one can assume in practice that APIs are realized with the REST style.

REST Style

REST (Representational State Transfer) is an architectural style for services, and as such it defines a set of architectural constraints and agreements. A service, which complies with the REST constraints, is said to be RESTful.

REST is designed to make optimal use of an HTTP-based infrastructure and due to the success of the web, HTTP-based infrastructure, such as servers, caches and proxies, are widely available. The web, which is based on HTTP, provides some proof for an architecture that not only scales extremely well but also has longevity. The basic idea of REST is to transfer the ideas that worked well for the web and apply them to web services.

HATEOAS Style

HATEOAS is an abbreviation for Hypermedia As The Engine Of Application State. HATEOAS is an extension of REST and any of the constraints and advantages of REST also apply to HATEOAS. HATEOAS has additional constraints, allowing for more dynamic architectures. These constraints allow clients to explore any API without any a-priori knowledge of data formats or of the API itself.

RPC Style

RPC is an abbreviation for Remote Procedure Call. RPC is an architectural style for distributed systems. It has been around since the 1980s. Today the most widely used RPC styles are JSON-RPC and XML-RPC. Even SOAP can be considered to follow an RPC architectural style.

The central concept in RPC is the procedure. The procedures do not need to run on the local machine, but they can run on a remote machine within the distributed system. When using an RPC framework, calling a remote procedure should be as simple as calling a local procedure.

SOAP Style

SOAP follows the RPC style and exposes procedures as central concepts (e.g. getCustomer). It is standardized by the W3C [21] and is the most widely used protocol for web services. SOAP style architectures are in widespread use, however, typically only for company internal use or for services called by trusted partners.

Conclusion

APIs can basically be realized using any of these styles. How do we know, whether a particular architectural style is appropriate for a given API? The resulting API exposes many of the previously stated desirable properties.

When should I use which style? Check the API Architecture Book.

Architectural Styles for APIs: SOAP, REST and RPC

One thought on “Architectural Styles for APIs: SOAP, REST and RPC

Comments are closed.