REST API between services in Microservices - System Design Guide

Problem Statement

When microservices communicate directly without a standard protocol, they risk tight coupling and inconsistent data exchange formats. This leads to fragile integrations where changes in one service break others, causing downtime and complex debugging.

Solution

Using REST APIs between services standardizes communication with HTTP methods and structured data formats like JSON. Each service exposes clear endpoints, enabling loose coupling and independent evolution while ensuring interoperability and easier debugging.

Architecture

Service A

→Service B

↓

Client App

→Service A

Diagram shows client and services communicating via REST APIs over HTTP, with Service A calling Service B through defined endpoints.

Trade-offs

✓ Pros

→

Standardized communication using HTTP and JSON makes integration straightforward.

→

Loose coupling allows services to evolve independently without breaking others.

→

Stateless requests improve scalability and fault tolerance.

→

Wide tool and library support simplifies development and testing.

✗ Cons

→

REST APIs can introduce latency due to network calls between services.

→

Lack of built-in message reliability requires additional handling for failures.

→

Versioning APIs can become complex as services evolve.

When services need clear, language-agnostic communication with moderate request rates (up to thousands per second) and require loose coupling.

When ultra-low latency or guaranteed message delivery is critical, or when service interactions are highly chatty and synchronous, consider alternatives like gRPC or message queues.

Real World Examples

Netflix

Uses REST APIs between microservices to enable independent deployment and scaling while maintaining clear service boundaries.

Uber

Employs REST APIs for communication between services like ride matching and payment processing to ensure modularity and fault isolation.

Amazon

Uses REST APIs extensively to allow diverse teams to build and maintain services independently with standardized communication.

Code Example

Before, ServiceA directly calls ServiceB's method, creating tight coupling. After, ServiceA sends an HTTP POST request to ServiceB's REST endpoint, enabling loose coupling and independent deployment.

Microservices

### Before: Direct function call tightly coupling services
class ServiceB:
    def process(self, data):
        return f"Processed {data}"

class ServiceA:
    def __init__(self):
        self.service_b = ServiceB()

    def handle(self, data):
        result = self.service_b.process(data)
        return f"ServiceA got: {result}"


### After: ServiceA calls ServiceB via REST API
from flask import Flask, request, jsonify
import requests

# Service B
app_b = Flask(__name__)

@app_b.route('/process', methods=['POST'])
def process():
    data = request.json.get('data')
    return jsonify({'result': f"Processed {data}"})

# Service A
class ServiceA:
    def handle(self, data):
        response = requests.post('http://serviceb/process', json={'data': data})
        result = response.json().get('result')
        return f"ServiceA got: {result}"

Alternatives

gRPC

Uses HTTP/2 with binary protocol for faster, strongly typed communication.

Use when: When you need high performance, low latency, and strict contract enforcement between services.

Message Queue (Event-driven)

Uses asynchronous messaging for decoupled, reliable communication without direct service calls.

Use when: When services require asynchronous processing and guaranteed message delivery.

Summary

REST APIs standardize communication between microservices using HTTP and JSON.

They enable loose coupling, allowing services to evolve independently and scale.

REST is best for moderate latency tolerance and stateless interactions but requires extra handling for reliability.

Practice

1. What is the main purpose of using a REST API between microservices?

easy

A. To allow services to communicate over HTTP using standard methods

B. To store data permanently in a database

C. To run services on the same machine only

D. To replace all backend logic with frontend code

Solution

1. Step 1: Understand REST API role in microservices

   REST APIs enable communication between independent services using HTTP methods like GET, POST, PUT, DELETE.

2. Step 2: Identify the correct purpose

   Storing data or running services on the same machine are not the main goals of REST APIs; they focus on communication.

3. Final Answer:

   To allow services to communicate over HTTP using standard methods -> Option A

4. Quick Check:

   REST API = communication over HTTP [OK]

Hint: REST APIs connect services via HTTP methods [OK]

Common Mistakes:

• Confusing REST API with database storage
• Thinking REST APIs run services locally only
• Assuming REST replaces backend logic

2. Which HTTP method is typically used to update an existing resource in a REST API between microservices?

easy

A. GET

B. PUT

C. POST

D. DELETE

Solution

1. Step 1: Recall HTTP methods and their purposes

   GET retrieves data, POST creates new data, PUT updates existing data, DELETE removes data.

2. Step 2: Match method to update action

   Updating a resource is done with PUT, which replaces or modifies the resource at the given URL.

3. Final Answer:

   PUT -> Option B

4. Quick Check:

   Update = PUT [OK]

Hint: PUT method updates resources in REST APIs [OK]

Common Mistakes:

• Using GET to update data
• Confusing POST with update instead of create
• Using DELETE to update resources

3. Consider this REST API call between two services:

GET /users/123

What is the expected result of this request?

medium

A. Retrieve details of the user with ID 123

B. Create a new user with ID 123

C. Delete the user with ID 123

D. Update the user with ID 123

Solution

1. Step 1: Analyze the HTTP method and URL

   The method is GET, which is used to retrieve data. The URL targets user with ID 123.

2. Step 2: Determine the action based on method

   GET requests fetch data without changing it, so it retrieves user details.

3. Final Answer:

   Retrieve details of the user with ID 123 -> Option A

4. Quick Check:

   GET /users/123 = retrieve user data [OK]

Hint: GET fetches data, not modifies it [OK]

Common Mistakes:

• Thinking GET creates or deletes data
• Confusing URL path with action
• Assuming GET updates resources

4. A microservice sends a POST request to another service's REST API but receives a 405 Method Not Allowed error. What is the most likely cause?

medium

A. The request body is missing required fields

B. The URL endpoint does not exist

C. The HTTP method POST is not supported by the endpoint

D. The server is down

Solution

1. Step 1: Understand 405 Method Not Allowed meaning

   This error means the server recognizes the URL but does not allow the HTTP method used.

2. Step 2: Match error to cause

   If POST is not supported on that endpoint, the server rejects it with 405. Other issues cause different errors.

3. Final Answer:

   The HTTP method POST is not supported by the endpoint -> Option C

4. Quick Check:

   405 error = method not allowed [OK]

Hint: 405 means method not allowed on endpoint [OK]

Common Mistakes:

• Confusing 405 with 404 (not found)
• Assuming missing fields cause 405
• Thinking server down causes 405

5. You design two microservices: Service A calls Service B's REST API to get user data. To improve scalability and reduce latency, which design choice is best?

hard

A. Service A calls Service B synchronously for every user request

B. Service A and B share a database to avoid API calls

C. Service B pushes user data to Service A via REST POST requests

D. Service A caches user data locally and refreshes periodically

Solution

1. Step 1: Evaluate synchronous calls impact

   Calling Service B synchronously for every request adds latency and load, reducing scalability.

2. Step 2: Consider caching benefits

   Caching user data locally in Service A reduces calls to Service B, improving response time and scalability.

3. Step 3: Assess other options

   Service B pushing data is complex and not typical REST usage; sharing a database breaks microservice independence.

4. Final Answer:

   Service A caches user data locally and refreshes periodically -> Option D

5. Quick Check:

   Caching improves scalability and latency [OK]

Hint: Cache data locally to reduce cross-service calls [OK]

Common Mistakes:

• Using synchronous calls for every request
• Sharing databases between microservices
• Expecting REST APIs to push data automatically