We need to introduce API rate limiting to ensure fair and equitable access to the system and to prevent abusive behaviour.
Every connection must be attributed to an API client. I see there a number of use-cases into which API clients can be bucketed:
Public trading interface
Personal copy of the ForkDelta interface
Trading bot
Utility client: a website, mobile app, or script that requests data, but does not place any orders
Public Trading Interface
A public trading interface allows a human user to retrieve data and post new orders. Connections are restricted to a specific set of Origin headers, and are rate-limited based on end-user IP address (based on the IP of the client connecting to our API). A public trading interface may additionally be limited to a finite number of simultaneous user connections. Currently, only one public trading interface will be allowed: the official ForkDelta interface.
Personal Copy of The ForkDelta Interface
A personal copy of the interface client is similar to a public trading interface client. A personal copy of the interface may not be accessible publicly from the Internet or indexable by Google (the interface can be restricted by being hosted on localhost, an IP address filter, HTTP authentication, or any other means ensuring no public access). A personal copy of the interface will be limited to a finite number of simultaneous user connections.
Trading Bot
A trading bot may receive data and post new orders to the website. A trading bot client is restricted to a specific set IP addresses or required to connect with a specified secret, and is rate-limited across all connections. Trading bot clients are subject to periodic audit of their API usage.
Utility Client
A utility client may receive data from the API, but is not allowed to post orders. A utility client is restricted to either a specific IP address, a specific set of Origin headers, or required to connect with a specific secret. The client is not rate-limited beyond the global limits.
Rate limiting
Rate limiting should occur based on the type of action performed by the client using the leaky bucket model. The bucket will be filled with the maximum amount of API "credits" upon initial connection, less the cost of the connection, based on the API client type. When the client connection issues a request, a number of API credits proportional to the cost of the associated operation will be subtracted. The subtraction may occur before or after the requested operation. If the client does not have sufficient credits to perform the operation, the API will respond with a defined error code. The bucket will be re-filled on a periodic basis and will expire after a fixed amount of time after creation.
Further Work
Exact values of API credits issued per connection per client type should be worked out.
A client application type can further be split into tiers based on the needs of an application.
We need to introduce API rate limiting to ensure fair and equitable access to the system and to prevent abusive behaviour.
Every connection must be attributed to an API client. I see there a number of use-cases into which API clients can be bucketed:
Public Trading Interface
A public trading interface allows a human user to retrieve data and post new orders. Connections are restricted to a specific set of
Originheaders, and are rate-limited based on end-user IP address (based on the IP of the client connecting to our API). A public trading interface may additionally be limited to a finite number of simultaneous user connections. Currently, only one public trading interface will be allowed: the official ForkDelta interface.Personal Copy of The ForkDelta Interface
A personal copy of the interface client is similar to a public trading interface client. A personal copy of the interface may not be accessible publicly from the Internet or indexable by Google (the interface can be restricted by being hosted on localhost, an IP address filter, HTTP authentication, or any other means ensuring no public access). A personal copy of the interface will be limited to a finite number of simultaneous user connections.
Trading Bot
A trading bot may receive data and post new orders to the website. A trading bot client is restricted to a specific set IP addresses or required to connect with a specified secret, and is rate-limited across all connections. Trading bot clients are subject to periodic audit of their API usage.
Utility Client
A utility client may receive data from the API, but is not allowed to post orders. A utility client is restricted to either a specific IP address, a specific set of
Originheaders, or required to connect with a specific secret. The client is not rate-limited beyond the global limits.Rate limiting
Rate limiting should occur based on the type of action performed by the client using the leaky bucket model. The bucket will be filled with the maximum amount of API "credits" upon initial connection, less the cost of the connection, based on the API client type. When the client connection issues a request, a number of API credits proportional to the cost of the associated operation will be subtracted. The subtraction may occur before or after the requested operation. If the client does not have sufficient credits to perform the operation, the API will respond with a defined error code. The bucket will be re-filled on a periodic basis and will expire after a fixed amount of time after creation.
Further Work