Best Practices

Rate Limit

Reducing the number of API requests
Make sure you make only the requests that you need. Here are areas to explore for reducing the number of requests:

Optimize your code to eliminate any unnecessary API calls
For example, are some requests getting data items that aren't used in your application? Are retrieved data items being put back to your Edunation account with no changes made to them?

Cache frequently used data
You can cache data on the server. You can also save relatively static information in a database or serialize it in a file.

Cache non-volatile data
Cache non-volatile data on your end whenever it is feasible. For e.g. the mapping between user name and ID is extremely unlikely to change. Hence, by caching it on the client side, you will be able to avoid API calls.

Regulating the request rate
If you regularly approach or bump into the rate limit, consider including a process in your code that regulates the rate of your requests so that they're distributed more evenly over time. This is known as a throttling process or a throttling controller. Regulating the request rate can be done statically or dynamically. For example, you can monitor your request rate and regulate requests when the rate approaches the rate limit.

To determine if you need to implement a throttling process, monitor your request errors. How often do you get 429 errors? Does the frequency warrant implementing a throttling process?

Catching errors caused by rate limiting
For each request, you can check to see if you've bumped into the rate limit. If you get a response code of 429, "Too Many Requests", you've hit the rate limit.

It's best practice to include code in your script that catches 429 responses. If your script ignores the "Too Many Requests" error and keeps trying to make requests, you might start getting null errors. At that point the error information won't be useful in diagnosing the problem.

๐Ÿ“˜

Contact us to increase the rate limit

As soon as you recognize that a rate limit increase will be required in the future, contact us. We have different pricing packages for rate limiting where we can allocate more resources to your API calls.

Other Best Practices

  • Avoid making API calls directly from a mobile app, rather send the request to your servers and make the API calls from there. This ensures that in the event of an API endpoint being modified, you will be able to make and deploy the change to your server rather than updating your app and forcing your users to the latest version.

  • Always use HTTP connection/multiplexing when making the API request. This will save some time while opening TCP connection to Edunation.

  • When retrieving a list of objects, avoid making calls referencing page numbers over 500 (deep pagination). These are performance intensive calls and you may suffer from extremely long response times.

  • All responses are cached for 30 seconds. This means for a specific end-point with the same parameters, you will always get a cached response if you make consecutive requests within 30 seconds.