What is the response time of the service should be when developing api?

Question

API

I searched long and hard but could not find any answer to this. In web development, a response time of 200ms is generally accepted, but again, this is not explicitly written anywhere. Are there any standards in which it is written in black and white how long the server should respond. For the web, for exchanges with erp systems and the like. If someone doesn’t know this, then anyway, I ask you to unsubscribe, who thinks what time is acceptable and how realistically achievable for projects based on 1C (meaning not Bitrix, but let’s say trade management), sap erp and other things like that.

Answer 1

In an old usability book it was said something like this:
0.1 s (or 100 ms) - the limit to which the user thinks that the system works instantly and no progress bars are required.
1 s (or 1000 ms) is the limit up to which the user notices a slight delay, but in general it seems to him that everything is working fine.
10 s (or 10 000 ms) - the user stops monitoring the process and it seems to him that the system has hung.
In general, the logic is simple: less is more. I think that the limit when everything can be considered OK is up to 1 second, better than 500 ms (unless, of course, we are talking about an API call in a cycle - then all requests must be within this limit). If the response makes more sense for the system (usually some user interface) that uses the API - add some kind of animation like a loading indicator - in this case, the user is more comfortable with longer response intervals, as he sees that the system is doing something. Usually, in a web application that crawls for data (especially if it is not one element at a time, but batch processing), an indicator is made into some external systems. You can quite simply hang some kind of animation on all AJAX calls using api.jquery.com/category/ajax/global-ajax-event-handlers- at start show at end hide. There are many ready-made solutions.

Answer 2

It depends on what kind of service and what it is eaten with.
I have several services that collect cron data. Here, there, in general, I don’t care 100ms or 10s for a request (exaggerated).
If you are doing something that requires the rapid exchange of information, then up to a second it is quite a working option. But then again, giving some json with a list of 10 news for a business card site for a second is not ice. Here it is necessary to understand.
If you cannot influence the giving service (1c, sap, etc.), the hardware is bad there, the data is complex, that is, there are a lot of options how to get rid of trouble here. Starting from the laying server, to the early request for information.
Here you have to dance from the situation.