REST API Architectural Constraints

In partnership with

Hello “👋”

Welcome to another week, another opportunity to become a Great Backend Engineer.

Today’s issue is brought to you by Alerty.ai → Alerty helps you monitor performance and errors in your app so you can grow the number of users for your product.

Before we get down to the business of today. I have a special gift for you: You will love this one.

The Daily Newsletter for Intellectually Curious Readers

• We scour 100+ sources daily

• Read by CEOs, scientists, business owners and more

• 3.5 million subscribers

Sign up today!

Now, back to the business of today.

We all know what RESTful APIs are but do we know what the RESTful API Architectural Constraints are?

REST which means Representational State Transfer is an architectural style that provides constraints to create a service that can be easily scalable, simple to use, and maintainable. One of the RESTs' core principles is applying specific architectural constraints.

There are 6 main architectural constraints:

1. Client Server

2. Uniform Interface

3. Statelessness

4. Caching

5. Layered System

6. Code on Demand

Now let’s discuss each of them in detail.

Client Server

The client-server architecture is a fundamental principle of the RESTful API architecture. It stipulates a clear distinction between the client and the server and the communication layer between the client and server.

Key Features

Let’s explore some of the features of the Client-Server architecture before we look into some examples that will help us understand properly.

1. Separation of Concerns: The client and server are separated, allowing them to evolve independently. The client focuses on the user interface and experience, while the server handles data storage, retrieval, and business logic.

2. Independent Development: Since both sides can operate independently, teams can develop and deploy client and server programs separately.

3. Simplified Scalability: The client-server separation allows for horizontal scaling. Servers can be scaled by adding more servers to handle increasing loads.

4. Responsibility: The client initiates requests to the server, and the server responds to those requests.

The idea of the Client-Server Architecture is about separating concerns between the client and the server. For instance, imagine you’re building a mobile/web application.

Then the business logic (Server) of the application is situated in this location https://api.example.com while the user interface (Client) is requesting resources from the server at the given location.

• The client initiates a request to https://api.example.com

• The server receives the request, processes it, and responds with the appropriate data in JSON format.

• The client then renders this data to the user interface.

That’s the idea behind the Client-server constraint that is built into RESTful APIs. If your API can be separated from your client. Then you have achieved the Client-Server Architectural constraint.

Uniform Interface

The Uniform Interface constraint is a fundamental principle in REST architecture. It ensures that the interfaces between the client and server are consistent and standardized, simplifying and decoupling the architecture, which further allows each part to evolve independently.

Key Features:

• Resource Identification in Requests: Resources are identified using URIs (Uniform Resource Identifiers). For example, a resource might be retrieved by accessing /users/123 to get user details.

• Manipulation of Resources through Representations: Clients interact with representations of resources. For instance, the server may provide a JSON representation of a resource the client can modify and send back in a PUT request.

• Self-descriptive Messages: Each message includes enough information to describe how it should be processed. This may include metadata like media types, HTTP methods, and response codes.

• Hypermedia as the Engine of Application State (HATEOAS): Clients can navigate the API dynamically by following hyperlinks provided in the responses without needing prior knowledge of the API structure.

Example: Imagine interacting with a RESTful service to manage users:

• Resource Identification: Access user with ID 123 using GET /users/123.

• Manipulation of Resources: Update the user with ID 123 using PUT /users/123 and providing the updated user info in JSON format.

• Self-descriptive Messages: The response might include HTTP status codes like 200 OK, and content types like application/json.

• Hypermedia: The response might include links to related resources, such as /users/123/friends to get the user's friends.

You have explored the "Uniform Interface" constraint—one of the key principles of REST architecture.

This constraint ensures consistent and standardized interactions between the client and server via resource identification, manipulation through representations, self-descriptive messages, and hypermedia as the engine of application state (HATEOAS).

Following this constraint simplifies the development process, allows independent evolution of client and server components, and enhances scalability and maintainability.

Stateless

The Stateless constraint is a fundamental principle in REST architecture. It simplifies interactions between the client and server by ensuring that each request from the client contains all the necessary information to understand and process the request.

Key Features:

• Self-contained Requests: Each request from the client to the server must contain all the information the server needs to fulfill that request. This can include authentication tokens, parameters, and any other necessary data.

• No Client Context Stored on the Server: The server does not store context about the client between requests. Each request is independent.

• Scalability: Since the server does not maintain a session state between requests, it can easily handle many requests from different clients, making it easier to scale.

• Resilience: Statelessness improves the service's reliability and predictability, as any server can handle requests in a stateless architecture without relying on the saved client state.

Example: Consider a RESTful service for user authentication:

• Stateless Authentication: Each request to access a resource includes an authentication token (e.g., JWT) in the header. The server validates the token and grants access without maintaining sessions.

• Stateful Authentication (Non-REST): The server maintains a session for each logged-in user; subsequent requests rely on the server-maintained session state.

You have explored the "Stateless" constraint—one of the key principles of REST architecture. This constraint ensures that each client request is self-contained and includes all the necessary information for the server to fulfill the request.

By adhering to this principle, server-side scalability and reliability are enhanced because the server does not need to maintain any state between requests.

Caching

The Caching constraint is a fundamental principle in REST architecture. It ensures that responses to client requests are cacheable, which can significantly improve performance, scalability, and user experience by reducing the need to generate the same response repeatedly.

Key Features:

• Response Caching: Servers specify cacheability of responses through HTTP headers like Cache-Control, Expires, and Etag.

• Reduced Load: By caching responses on the client side or intermediate proxies, the number of interactions with the server is reduced, lowering the server load.

• Improved Performance: Cached data can be retrieved faster than the requested data from the server, providing a more responsive user experience.

• Staleness Control: Servers can control how long a response is fresh and specify conditions under which the cache must be validated before reusing.

Example:

• Cache-Control Header: A server sends Cache-Control: max-age=3600 In an HTTP response, indicating the client can reuse the response for the next 3600 seconds without contacting the server.

• Etag Header: A server sends an ETag (Entity Tag) in the header, which clients can use to validate the cached content. Clients can send the ETag in subsequent requests using the If-None-Match header to check if the resource has changed.

You have explored the "Caching" constraint—one of the key principles of REST architecture. The caching constraint ensures that responses to client requests are cacheable, which can significantly improve the performance and scalability of web services by reducing redundant server requests and enabling quicker response times.

By setting appropriate HTTP headers like Cache-Control and ETag, servers can control the cache behavior, making responses cacheable for a specified duration or validating cached responses based on changes in the resource.

Layered System

The Layered System constraint is a fundamental principle in REST architecture. It enforces a hierarchical organization of components, which can be independently managed, improving scalability and security.

Key Features:

• Hierarchical Layers: The architecture is divided into layers, with each layer only interacting with the layer immediately below it.

• Encapsulation: Each layer encapsulates its internal implementation details from the layers above. Clients and servers can’t bypass the layer underneath to access functionality directly.

• Independence: Changes in one layer do not affect others, enabling better modularization and independent evolvability.

• Intermediary Layers: Layers can include additional intermediaries like proxies, gateways, or load balancers to improve performance, enforce security policies, and balance loads.

Example: Consider a web application:

• Client-Layer: The client layer includes the web browser or mobile app that interfaces with the RESTful API.

• Intermediary Layer: This layer could include a CDN (Content Delivery Network) for efficient resource delivery or a reverse proxy for load balancing and caching.

• Server-Layer: The application server processes client requests and handles business logic.

• Database Layer: The database server stores and retrieves data as requested by the application server.

You have explored the "Layered System" constraint—one of the key principles of REST architecture. The layered system constraint ensures that the architecture is divided into hierarchical layers where each layer only communicates with its immediate neighbor.

This approach improves modularity, simplifies maintenance, enhances scalability, and improves security via intermediary layers such as proxies and gateways.

By encapsulating the details within each layer, changes in one layer do not directly affect others, resulting in a more robust and manageable system.

The provided example included a middleware acting as an intermediary layer in a basic Node.js Express application to demonstrate this layered approach in practice.

Code on Demand

The "Code on Demand" constraint is an optional feature in REST architecture. It allows servers to deliver executable code to the client, which can extend the client's functionality on the fly.

Key Features:

• Dynamic Client Capabilities: Clients can download and execute code provided by the server, dynamically extending their functionalities.

• Flexibility: This allows the functionality to change without requiring a client update.

• Example Usage: Common examples include JavaScript code sent to browsers, applets, or scripts that can be executed in the client's environment.

Example:

• JavaScript in Web Applications: A server might deliver JavaScript code that the client-side browser executes to provide dynamic content or interactive features.

"Code on Demand" offers significant flexibility for creating dynamic applications that can be updated on the fly. However, using it requires careful consideration of security implications and a balanced approach to dependency on dynamism.

That will be all for this week. I like to keep this newsletter short.

This is from the API and API Design series for backend engineers. You can bookmark it for further reading.

Don’t miss it. Share with a friend

Did you learn any new things from this newsletter this week? Please reply to this email and let me know. Feedback like this encourages me to keep going.

See you on Next Week.

Remember to sign up to Alerty.ai → Alerty helps you monitor performance and errors in your app so you can grow the number of users for your product.

Top 5 Remote Backend Jobs this week

Here are the top 5 Backend Jobs you can apply to now.

👨‍💻 Oowlish Technology
✍️ Backend Developer - Nodejs
📍Remote
💰 Click on Apply for salary details
Click here to Apply for this role.

👨‍💻 Oowlish Technology
✍️ Backend / API Engineer, Issuing
📍Remote, Canada
💰 Click on Apply for salary details
Click here to Apply for this role.

👨‍💻 Arista Networks
✍️ Backend Engineer, AdTech
📍Remote, Germany
💰 Click on Apply for salary details
Click here to Apply for this role.

👨‍💻Sandman Media Inc
✍️ Full stack PHP Developer
📍Remote, Africa
💰 Click on Apply for salary details
Click here to Apply for this role.

Want more Remote Backend Jobs? Visit GetBackendJobs.com

GBE Podcast

In this week’s episode of the Great Backend Engineer (GBE) podcast, I sat down with Johnny Dallas to discuss building better software using internal tools.

Watch on Youtube (subscribe):

Spotify:

Apple Podcast:

Backend Engineering Resources

1. Backend Engineering Hub

2. All Backend Books

3. Visit our Backend Store

4. Join our Community

5. Backend Engineering Courses

6. Great Backend Engineering Podcast

LAST WORD 👋 

How am I doing?

I love hearing from readers, and I'm always looking for feedback. How am I doing with The Backend Weekly? Is there anything you'd like to see more or less of? Which aspects of the newsletter do you enjoy the most?

Hit reply and say hello - I'd love to hear from you!

Stay awesome,
Solomon

I moved my newsletter from Substack to Beehiiv, and it's been an amazing journey. Start yours here.