API Architecture RestFul

  

The API must support 100 requests per second.

  

Let's separate the responsibilities here.

The responsibility of the developer is to create a performatic API that supports simultaneous and clustered requests, that is, there can be more than one instance of the API running on different servers connecting many users to the same base data.

This means that if your API receives, for example, two different sources, a request to delete and update the same information, your application should handle this without conflicts, inconsistency, and without loss of performance. >

The responsibility of devops is to create a hosting of your application, where you can scale individually, without needing to change the application, specific points of the solution - scale, horizontally or vertically, only API, or just the database, or the storage, etc.

The two sums are where you will arrive at your "100 req / sec".

Example , the overall average latency - time between request and response - your application is 60ms empty - with only one client - but from 500 clients the latency rises to 100ms. After investigating, it is perceived that the bottleneck is API processing - since, superficially, it may be database access, storage access, network connection - then scaling the API is the beginning of the solution. You should now investigate and decide to scale horizontally - create more instances of your API responding to your clients, with due load balance - or vertically - increasing the resources allocated to your application, such as colors or memory, increasing processing power.

These guidelines are very superficial, especially since we do not know the business of the API. If it is only to process data - without connecting to any database or storage - it is simpler than doing this with an API that performs image interpretation, which requires access to several other resources, and still has the characteristic of being intensive .

  

The API should foresee failures of integration between APIs, not leaving the client with no response.

  

There may be several approaches for this requirement. To get started, you can set some filters . So your application can intercept requests in request and response . Having some flaws, it is there and returns a standardized exception context for your client.

I do not like it. And, I'm not sure, but I do not think it's a good practice. The ideal IMHO is to validate the request data, if there is a problem, return an HTTP 400 - Invalid request , and to actually fail your API, return > HTTP 500 - Internal Server Error .

It will be very strange an API to return something other than HTTP 500, but in the body of the response it has failed.

I recommend you read this project guide for an API . You have a lot of cool guidelines.