JASPER:API/API Policies and best practices

Ylbtech-jasper:api / API policies and best Practices

1. back to top

1. API Policies and best practices

Cisco Jasper has established an API fair usage policy to ensure that all Control Center users have the best experience possible. Any client code that uses the Control Center API must comply with the following restrictions.

Concurrent connections

Cisco Jasper recommends that the enterprise avoid concurrent processing because it can significantly slow down the response. We recommend that you use the API only in single-threaded applications or routines. Accounts that use the API in multithreaded situations may be subject to current limits or other restrictions, depending on the environment.

policy : Use single-threaded code-one API call at a time .

Number of calls per second

Cisco Jasper ensures reliable API performance by limiting the number of API calls per second that the account can make. If your account exceeds the limit, subsequent API calls within the measurement period (one second) will get the response shown in the following table based on the API type. After the appropriate delay, the program should retry the API call.

API Type	Return Code	message
REST	40000029	Exceeding Tariff limits
Soap	400101	License has exceeded the tariff limit for API calls

As we continually adjust the optimization platform to improve speed and reliability,Cisco Jasper may occasionally update the number of calls per second limit. If you use the best practices described below (single-threaded code, dynamic rate limiting, and so on), this restriction will not have an impact. When needed, operators can provide more detailed information about this limitation.

Please note that this limit includes API calls made by customers of accounts and accounts. For example, if an account has two-bit API users and their 5-bit customers make API calls at the same time, Control Center counts the total number of calls per second for that account as 7. The initial API call succeeds, but after the limit is reached, the remaining API calls return one of the messages shown above.

This restriction also applies to the combination of REST and SOAP API calls. For example, suppose an account makes 1 REST API calls and 1 SOAP API calls at the same time, and one of the clients of that account makes a REST API call. Control Center counts the number of calls per second for that account to 3.

policy . Use dynamic rate limiting and other best practices to comply with this limitation.

Best practices

The following tips can help you avoid throttling or other usage limits that may occur when the API is being used too much.

Add rate Limit Code

The best way to avoid exceeding the limit of calls per second is to create single-threaded code. However, you may experience an unavoidable situation. For example:

• Multiple API users are making calls.
• You need to use both REST and SOAP functions.
• You have a large number of calls that require multi-threaded processes.

In these cases, we recommend that you create a rate limiting routine that monitors and adjusts your API calls. For example, if an account receives multiple error messages while processing a call, you can introduce a wait time between the API calls. You can increase this wait time until the error no longer occurs.

Virtual code example. The following virtual code demonstrates how the rate-limiting code works.

Disclaimer:this EXAMPLE is provided for illustration purposes only,And without WARRANTY of any KIND, EXPRESS OR impliedwhile(<<list is not empty>>){Api_call attempts to perform a action to update the DEVICE statusIt returns the API response code response=Api_call(<<list element>>)API call returns the "limit exceeded" error, increase loop delay IF(Response= = error_limit_exceeded){Delay+= adjust_delay_incr } ELSE { //ensure delay never goes below 0 IF (DELAY > Adjust_delay_ DECR ) {delay -= ADJUST_DELAY_DECR } ELSE {delay = 0 } } sleep( Delay )}                 

Adjust Call frequency

When tracking device usage through the API, you must keep the frequency of your API calls consistent with the operator's update frequency .

For example, if your carrier updates usage information every 6 hours, you cannot request information through the API more often than once every 6 hours. In addition, there is usually a delay between the time that the usage data is available and the time that Control Center receives the usage data from the operator. Sometimes, the delay can be up to 24 hours.

Using the cache

The Cisco Jasper encourages the use of local caches . For example, you can create a simple routine that checks the cache once a day instead of calling the API every time the page is loaded.

Restricting API calls with filters

Avoid unnecessary API calls by checking for specific conditions before executing the program. For example:

• If the device is deactivated, do not check for usage.
• If the customer does not request device usage, do not check every hour.

Extend the interval between searches

If you receive an API response that is empty or unchanged, extend the query interval. For example, consider changing the query from once every two hours to one day at a time.

2.

2. back to top

3. back to top

4. back to top

5. back to top

6. back to top

Ylbtech Source: http://ylbtech.cnblogs.com/ This article is copyright to the author and the blog Park, Welcome to reprint, but without the consent of the author must retain this paragraph, and in the article page obvious location to the original link, otherwise reserves the right to pursue legal responsibility.

JASPER:API/API Policies and best practices