Low latency, high payload, high volume API gateway
View Patent ↗An API gateway designed to process a high volume of API requests for data and services where relatively large payloads are returned to the requester. The API gateway includes an “on-line” component that, for each API request, examines information in the request to increment an API usage count by API ID and product key. The usage information is periodically pushed to an outbound message queue, where it is later populated in a database. An “off-line” component determines if a customer has exceeded its predetermined quota based on the information in the database. This determination is pushed to another message queue that is periodically read by the on-line component to update the in-memory API ID, product key and API validity flag values. As such the on-line component is able to service a high volume of API requests for data with a low latency.
1. A method for receiving and processing Application Programming Interface (API) requests at an API gateway, comprising:
receiving an API request at a first component executing on a computing device, wherein the first component is provided as an in-memory component and executes at a first priority to examine at least one of an API ID, an API key, a secret digest and an API validity flag to perform authentication of the API request;
authenticating the API key and the secret digest contained in the authenticated API request;
incrementing an API usage value that is compared by a second component to a predetermined quota associated with a user making the API request, wherein the second component is provided as an off-line component that executes at a second priority that is lower than the first priority to determine if the user has exceeded the predetermined quota based on the API usage value in a database;
providing access to API services in accordance with the API key and the API validity flag;
periodically pushing the API usage value to a message queue that is processed by the second component executing on the computing device; and
periodically updating the API validity flag used by the first component with usage information provided by the second component.
2. The method of claim 1 , further comprising:
incrementing the API usage value in accordance with the API ID and a product key;
placing the API usage value in an outbound message queue; and
populating the API usage value in the database.
3. The method of claim 1 , further comprising placing, by the off-line component, usage information into an inbound queue that is periodically read by the in-memory component to update an in-memory API ID, the product key and the API validity flag.
4. The method of claim 1 , further comprising determining if the API request should be throttled in accordance with the usage information.
5. The method of claim 1 , the periodically updating the API validity flag used by the first component with usage information provided by the second component further comprising reading, by the first component, the message queue to update an in-memory API ID, the API key and API validity flag values.
6. The method of claim 1 , further comprising performing validity checks on the API request and the API Key.
7. The method of claim 1 , further comprising authenticating the API request by comparing the secret digest from API request with a calculated secret digest.
8. The method of claim 1 , further comprising:
receiving a second API request at a second first component executing on the computing device;
authenticating a second API key and a second secret digest contained in the second API request;
incrementing a second API usage value that is compared by the second component to a second predetermined quota associated with the user making the API request;
providing access to the API services in accordance with the second API key and a second API validity flag;
periodically pushing the second API usage value to the message queue that is processed by the second component executing on the computing device; and
periodically updating the second API validity flag used by the second first component with usage information provided by the second component.
9. The method of claim 1 , further comprising throttling the API request in accordance with the usage information provided by the second component.