What are the API Architectural Styles?

The diagram below shows the common API architectural styles at a glance.

🚀Let's take a closer look at the different architectural styles.

🤔How often do you know what architectural patterns are available?👀

🚀REST:

Proposed in 2000, REST is the most commonly used style. It is often used between frontend clients and backend services. It is compliant with 6 architectural constraints. The common payload formats can be JSON, XML, HTML, or plain text.

The six architectural constraints are:

• Uniform interface
• Stateless
• Cacheable
• Code on demand
• Layered system
• Client-server

🚀GraphQL:

GraphQL was proposed in 2015 by Meta. It provides a schema-based and type system suitable for complex systems where the relationships between entities are graph-like.

Let's understand it through the diagram. GraphQL can retrieve user and order information in one request, whereas in REST, it requires multiple calls to get the information for user and order.

GraphQL is not a replacement for REST. It can be built upon existing REST services.

🚀WebSockets:

WebSockets are a protocol that provides full-duplex communication over TCP. Clients establish WebSockets to receive real-time updates from the backend services.

Unlike REST, which always pulls data, WebSockets enable pushing.

🚀Webhooks:

Webhooks are usually used for third-party asynchronous API calls.

Let's understand how it works under the hood.

As shown in the diagram, we use Stripe and PayPal for payment channels and register a Webhook for payment results. When a third-party payment service is done, it notifies the payment service if the payment is successful or failed. Webhook calls are usually part of the system's state machine.

🚀gRPC:

Released in 2016, gRPC is used for communications among microservices. The gRPC library handles encoding/decoding and data transmission.

🚀SOAP:

SOAP stands for Simple Object Access Protocol. Its payload is XML only, suitable for communications between internal systems.