APIs & REST Flashcards
What is Multi-Tenancy in Microservices?
Multi-tenancy is an architectural approach where a single application serves multiple tenants (organizations, customers, or users) while keeping their data and configurations separate.
Types of Multi-Tenancy:
1. Database Per Tenant: Each tenant gets a separate database.
o ✅ Strong isolation
o ❌ High operational cost
2. Schema Per Tenant: One database with separate schemas for each tenant.
o ✅ Moderate isolation
o ❌ Increased maintenance complexity
3. Shared Database, Shared Schema: A single database and schema with tenant-specific columns.
o ✅ Cost-efficient
o ❌ Requires strong access controls
Implementation in Spring Boot:
* Tenant Identification: Use request headers, subdomains, or JWT claims.
* Hibernate Multi-Tenancy: Use MultiTenantConnectionProvider and CurrentTenantIdentifierResolver.
* Database Routing: Implement dynamic data sources using AbstractRoutingDataSource.
* Security & Access
**Implementation Strategies in Microservices
**
Tenant-Specific Microservices: Some services are deployed specifically for particular tenants, especially for high-value customers with unique requirements.
Shared Microservices with Tenant Context: Most services are multi-tenant, using a tenant identifier in each request to determine which data to access.
API Gateway Tenant Resolution: The API gateway authenticates users, identifies their tenant, and adds tenant context to requests before routing them to microservices.
Sidecar Pattern: Deploy tenant-specific configuration as sidecars alongside shared microservices.
What are the principles of RESTful API design?
1. Client-Server:
This principle emphasizes the separation of concerns between the client and the server.
The client handles the user interface and user experience, while the server handles data storage and processing.
This separation allows each component to evolve independently.
2. Stateless:
Each request from a client to a server must contain all the information needed to understand and process that request.
The1 server does not store any client2 context between requests.
This statelessness simplifies server design and improves scalability.
- 3. Cacheable:
Responses from the server can be cached by clients or intermediaries to improve performance.
RESTful APIs should provide mechanisms to indicate whether a response is cacheable and for how long.
Caching reduces server load and improves response times. - Uniform Interface:
This is a fundamental principle that simplifies and decouples the architecture. It consists of several sub-principles:
Resource Identification: Resources are identified in requests using URIs (Uniform Resource Identifiers).
Resource Manipulation Through Representations: Clients manipulate resources by sending representations of those resources to the server.
Self-Descriptive Messages: Messages contain enough information for the client to process them.
Hypermedia as the Engine of Application State (HATEOAS): Clients can discover available actions and resources by following links in the responses.
5. Layered System:
The architecture can consist of multiple layers, such as load balancers, proxies, and security layers.
Each layer should be independent, and clients should not be able to tell whether they are communicating directly with the end server or an intermediary.
This improves system scalability and security.
What are the key principles of REST APIs?
o The key principles of REST APIs include statelessness, uniform interface, resource-based architecture, self-descriptive messages, and hypermedia as the engine of application state (HATEOAS). These principles promote simplicity, modularity, and independence between client and server components.
How does a REST API achieve statelessness?
REST APIs achieve statelessness by ensuring that each request from the client to the server must contain all the information required to understand and process the request. The server does not retain any session information about the client between requests, simplifying scalability and reducing coupling.
The uniform interface principle ?
The uniform interface principle establishes a standardized set of operations that all resources in a REST API should support. This includes using HTTP methods (GET, POST, PUT, DELETE) for specific actions on resources, consistent naming conventions, and using hyperlinks to navigate between resources.
A REST API (Representational State Transfer Application Programming Interface) is a way for computer systems to communicate with each other over the internet. It’s a set of rules that developers follow when creating APIs. Here’s a breakdown:
How is resource-based architecture employed in REST APIs?
REST APIs follow a resource-based architecture, where each piece of data or functionality is represented as a resource. Each resource is identified by a unique URI (Uniform Resource Identifier), and clients can interact with these resources using standard HTTP methods.
What are common best practices when designing REST APIs?
Some common best practices for designing REST APIs include using meaningful and consistent resource naming, adhering to HTTP methods semantics, leveraging caching mechanisms for performance optimization, providing clear and concise documentation, and implementing proper security measures like authentication and authorization.
What are the benefits of using REST APIs?
REST APIs (Representational State Transfer Application Programming Interfaces) offer numerous benefits for modern application development:
Simplicity and standardization - REST uses standard HTTP methods (GET, POST, PUT, DELETE) making it intuitive and easy to understand.
Statelessness - Each request contains all information needed to complete it, eliminating server-side session management and improving scalability.
Cacheability - REST responses can be cached, reducing server load and improving performance.
Client-server separation - The interface is separated from data storage, allowing each to evolve independently.
Platform independence - REST enables communication between systems built on different technologies (JavaScript, Python, Java, etc.).
Wide adoption - REST is broadly supported across the industry with extensive documentation and tooling.
Lightweight data exchange - Typically using JSON or XML for data formatting, REST is more bandwidth-efficient than alternatives like SOAP.
Excellent for public APIs - Its simplicity makes REST ideal for APIs consumed by multiple clients or third-party developers.
Scalability - The stateless nature and caching
capabilities make REST APIs highly scalable for high-traffic applications.
Flexibility - REST can support multiple data formats and is adaptable to changing requirements.
What are the key principles of REST APIs?
The key principles of REST APIs include statelessness, uniform interface, resource-based architecture, self-descriptive messages, and hypermedia as the engine of application state (HATEOAS). These principles promote simplicity, modularity, and independence between client and server components.
Why Services should not rely on local session data.
Services should avoid relying on local session data primarily for these reasons, which are crucial for scalability and reliability in distributed systems:
Scalability (Horizontal Scaling):
In a horizontally scaled system, you add more servers to handle increased load. If session data is stored locally on each server, a user’s subsequent requests might be routed to a different server that doesn’t have their session. This would result in a broken user experience, as the user would appear to be logged out or lose their context.
To maintain session consistency, you’d need to implement complex and inefficient session replication or synchronization between servers.
By externalizing session data, any server can access it, regardless of which server handled the initial request.
Fault Tolerance and Reliability:
If a server with local session data crashes, all sessions stored on that server are lost. This can lead to significant user disruption.
Externalizing session data to a centralized, highly available store (like Redis or a database) ensures that sessions are preserved even if individual servers fail.
Load Balancing Efficiency:
Load balancers can more effectively distribute traffic when services are stateless. If session data is local, the load balancer might need to use “sticky sessions” to ensure that a user’s requests are always routed to the same server. This limits the load balancer’s ability to distribute traffic evenly.
Stateless services allow the load balancer to distribute requests to any available server, maximizing efficiency and performance.
Simplified Architecture:
Externalizing session data simplifies the architecture of your services. You don’t need to worry about session replication or synchronization.
This leads to easier maintenance, deployment, and overall system managment.
Microservices Architecture:
In microservices architectures, services should be independent and loosely coupled. Local session data creates dependencies between services and hinders their independent scalability and deployment.
How to Handle Session Data:
Instead of local session data, use these approaches:
Centralized Session Store:
Use a dedicated session store like Redis, Memcached, or a distributed database. These stores are designed for high performance and availability.
JSON Web Tokens (JWTs):
Store session data in a JWT and send it with each request. The service can then verify the JWT and extract the session data. This approach is stateless and scalable.
In summary, avoiding local session data is essential for building scalable, reliable, and maintainable distributed systems.
