Architecture API Restful

Question

I’m building a Restful API with spring MVC and I have 2 non-functional requirements that I don’t understand how to attack them.

1. The API must support 100 requests per second;
2. The API should provide failures of integration between Apis, not leaving the customer without no response.

What spring mvc components can I use to meet these 2 requirements? Or how can I plant the architecture? Any ideas?

Answer 1

1. The API must support 100 requests per second.

Let’s separate the responsibilities here.

The responsibility of the developer is to create a performative API, which supports simultaneous and clustered requests, that is, there may be more than one instance of the API, running on different servers, connecting numerous users to the same database.

That is, if your API receives, for example, from two different sources, a request to delete and update the same information, your application should handle this without conflicts, incoherence, and without loss of performance.

The responsibility of devops is to create a hosting of your application, where you can scale individually, and with no need for changes in the application, specific points of the solution - scale, horizontally or vertically, only the API, or only the database, or the Storage, etc.

The two summed up is where you will arrive in your "100 req/sec".

Example, the overall average latency - time between request and sponse - of its application is 60ms empty - with only one client - but from 500 clients the latency rises to 100ms. After investigating, you notice that the bottleneck is API processing - since, superficially, it can be database access, Storage access, network connection - so scaling the API is the start of the solution. Now one should investigate and decide to scale horizontally - create more instances of your API responding to your customers, with due load - or vertically - increasing the resources allocated to your application, such as more colors or memory, increasing processing power.

These guidelines are very superficial, mainly because we do not know what the API business is. If it is just processing data - without connecting to any database or Storage - it is simpler than to do this with an API that does image interpretation, which requires access is several other features, and still has feature to be Processing Intensive.

2. The API should predict integration failures between Apis, leaving the client with no response.

There may be several approaches for this requirement. To begin with, one can define some Filters. So your application can intercept requests on request and in the sponse. Having some fault, it is there and returns a standard exception context to your client.

I don’t like it. And, I’m not sure, but I believe it’s not good practice. Ideally, IMHO, is to validate the data from request, if there are problems, returns a HTTP 400 - Invalid request, and really fail in your API, returns HTTP 500 - Internal server error.

Will be very strange an API returning something other than HTTP 500, but in the body of the response it came up a failure.

I recommend you take a look at this Project guide for an API. It has several very legal guidelines.