Designing API architecture is a systematic process that directly affects integration speed, total cost of ownership, and the resilience of business processes.
Let's walk through each step to build an effective solution. 1. Analysis of goals and requirements.
At this stage, it is important to gather the key requirements.
Functional requirements describe what the API should do:
- for example
- retrieving product data
- creating orders
- managing accounts
Non-functional requirements cover performance, security, and scalability, such as a 200 ms response time or support for 1000 concurrent users. Example:
For an e-commerce API, functional requirements include fetching the product assortment and placing orders.
Non-functional - HTTPS encryption, handling 1,000 RPS
1. Choosing an architecture style.The choice of architectural style determines how the API should interact with clients.
Main options (we covered the architecture styles in detail above): - REST: suitable for web applications where ease of integration matters (Microsoft Learn). - SOAP: suitable for complex transactions with high security requirements (banking systems).
Less flexible, but reliable
- GraphQL: ideal for mobile apps where optimization matters. When choosing, consider: -
Project goals: REST for simplicity, SOAP for security, GraphQL for flexibility. -
Compatibility with existing systems and technologies. -
The team's expertise: REST is simpler for most developers. -
Future needs: GraphQL makes API evolution easier. Example:
For a mobile app, GraphQL optimizes requests, while for a banking system, SOAP provides reliability. 1. Resource design.This step defines which data and functions the API exposes.
Resources are business entities: "users", "products", "orders", each with unique identifiers. At this stage, it is important to: -
Identify the key entities: for example, in a blog API, "posts", "comments", "authors". -
Specify attributes: for a "user" - id, name, email. -
Set relationships: "user" has "orders", "order" contains "items". -
Use clear names: plural for collections (/users), singular for individual resources (/users/123). -
Avoid deep nesting: instead of /users/123/orders/456/items, use URIs for related resources. -
Support filtering and pagination: for example, /posts?author=456 to filter by author. 1. Define operations.Operations define how the client interacts with resources through HTTP methods: - GET:
Retrieves data (example: GET /users/123 - request for information about user ID 123). - POST:
Creates a new resource (example: POST /users - adds a new user). - PUT:
Fully updates the resource (example: PUT /users/123 - replaces all data for user 123). - PATCH:
Partially updates a resource - changes the specified fields (example: PATCH /users/123 - updating user 123's email). - DELETE:
Deletes the resource (example: DELETE /users/123 - deletes user with ID 123). Tips: -
Follow HTTP standards for intuitive design. -
Define the allowed methods for each resource. -
Account for authentication: for example, DELETE requires administrator privileges. -
Document operations by listing parameters and responses
Example:For /posts: GET /posts - list posts, POST /posts - create a post, DELETE /posts/123 - delete a post. 1. Version management.Lets you update the API without disruptions for clients.
Key strategies: - URI versioning: /v1/users, /v2/users - a simple and clear approach. - Headers: Accept: application/vnd.company.users.v1+json - flexible, but more complex. - Request criteria: /users?version=1 - less reliable. Tips: -
Plan new version releases and support for older ones. -
Ensure compatibility so v1 clients keep working. -
Notify users about deprecation of older versions in advance. -
Use URI versioning for simplicity (Stack Overflow). Example:
If v1 has /users and v2 adds /profiles, v1 clients keep working unchanged.