Grokking the Frontend System Design Interview/

...

/

API Architectural Styles for Frontend Communication

API Architectural Styles for Frontend Communication

Learn about the different API architectural styles for communication in frontend System Design.

We'll cover the following...

Application programming interfaces (APIs) are essential for communicating with backend services while designing frontend systems, and APIs can take several different forms. In this lesson, we’ll discuss architectural styles for APIs and how they differ. Moreover, we’ll examine which architectural style suits each use case.

What is an architectural style?

An architectural style defines standardized rules and protocols for designing APIs, ensuring efficiency and consistency. Like design patterns, these styles provide a structured approach, impacting the entire development life cycle.

When determining an architectural style, we must evaluate the characteristics that suit our design problem. Each style practically serves as a template with constraints, so we must see which suits our requirements. Let’s take a look at some of the properties we may wish to integrate:

Architectural Style Properties

Characteristic

Description

Performance

Choosing an API to perform well and not to become a bottleneck with a large influx of requests.

Scalability

Opt for an API to be easily scalable, such as adding more features and capacity to the back-end servers.

Ease of development

Developers often choose a simple and familiar style to implement a solution.

Portability

The ability to move an API architecture style from one software environment to another.

Software maintenance support

There is ample support offered by the API providers.

Moreover, choosing the right style depends on factors like API consumers, business needs, and functionality, as switching later can be complex.

Press + to interact
Constraints that decide an API architecture style
Constraints that decide an API architecture style

Types of API architectural styles

We’ll consider three commonly used architectural styles. Each style has pros and cons, and even if most developers adopt REST, it may not be suitable for our design problem.

REST

Representational state transfer (REST) is a well-known web architecture style proposed by Roy Fielding in 2000Roy Fielding originally presented REST in his Ph.D. dissertation. [R. T. Fielding, Architectural Styles and the Design of Network-based Software Architectures. University of California, Irvine, 2000.] to solve the web’s scalability problem. Roy Fielding identified that certain key constraints could direct the web’s scalability, collectively called the web’s architectural style. Further, these constraints also act as a backbone for designing REST APIsAn API that follows the REST constraints is called REST or RESTful API..

An overview of the REST constraints is provided in the following table:

REST Constraints Overview

Constraints

Features

Drawbacks


Client-server


  • Improves evolvability of clients and servers.
  • Increases scalability.
  • An enormous number of user requests can overload the server.
  • Network disconnectivity may cause an interruption in services.


Cache


  • Reduces latency by storing data on the client side.


  • Reduces consistency if the stale data in cache varies considerably from the data in the recent response from the server.


Stateless

  • Improves reliability.
  • Increases scalability of the term of incoming requests.
  • Improves visibility of requests for analysis.
  • Reduces the network performance by sending repetitive data in a series of requests.


Uniform interface

  • Improves independent development of components.
  • Smoothens the interactions of entities.
  • Improves evolvability of the components.
  • Degrades the efficiency and flexibility because the information has to be sent in a standardized form rather than as required by the application.



Layered system

  • Improves evolvability and reusability of different components.
  • Enhances decoupling of the components.


  • Reduces the performance by increasing the processing overhead of different layers.
  • High security is needed at each layer to keep communication secure.


Code-on-demand


  • Improves extensibility.
  • Increases performance.
  • Reduces the trackability of the requests by the monitoring systems.
  • May sometimes compromise the security of the client.

Note: Adhering to all six constraints is only possible in an ideal scenario. As we have seen, some of the constraints are conflicting, for example, if we conform to the stateless constraint, we can achieve visibility; however, using the code-on-demand constraint reduces the visibility of the full nature of the request. Therefore, API designers should follow ...