From 19bbd2f7b9ff9d0157a57e710cc2e5787ff21e0f Mon Sep 17 00:00:00 2001 From: 1000101 Date: Tue, 25 May 2021 01:33:58 +0200 Subject: [PATCH 1/2] release: 0.1.15 -> 0.1.16 --- CHANGELOG.md | 9 +++++---- package.json | 2 +- swagger.yaml | 2 +- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index ee6d3463..2e08ffd1 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,27 +5,29 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project will adhere to [Semantic Versioning](https://semver.org/spec/v2.0.0.html) once it reaches maturity in v1. -## [] - Unreleased +## [0.1.16] - 2021-05-25 ### Added - `/accounts/{stake_address}/addresses/assets` endpoint to list all assets on addresses related to a given stake_address (account) - `/epochs/latest/parameters` and `/blocks/latest/txs` endpoints to list the current information about latest epoch and block +### Fixed + +- `onchain_metadata` in `/assets/{asset}/total` endpoint that could have been missing in some special cases + ## [0.1.15] - 2021-05-19 ### Fixed - `registration` and `retirement` arrays in `/pools/{pool_id}/` endpoint doesn't need to be `Nullable` - ## [0.1.14] - 2021-05-19 ### Fixed - `amount` in `/accounts/{stake_address}/rewards`, `/accounts/{stake_address}/delegations` and `/accounts/{stake_address}/history` endpoints doesn't need to be `Nullable` - ## [0.1.13] - 2021-05-06 ### Fixed @@ -43,7 +45,6 @@ and this project will adhere to [Semantic Versioning](https://semver.org/spec/v2 - all occurences of `epoch` to `active_epoch` in `/accounts/{stake_address}/history` endpoint - required properties of multiple endpoints and error messages - ## [0.1.11] - 2021-04-23 ### Added diff --git a/package.json b/package.json index d6d728d7..b4d75845 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "@blockfrost/openapi", - "version": "0.1.15", + "version": "0.1.16", "description": "OpenAPI specifications for blockfrost.io", "repository": "git@github.com:blockfrost/openapi.git", "author": "admin@blockfrost.io", diff --git a/swagger.yaml b/swagger.yaml index b0272ba2..dbb7037e 100644 --- a/swagger.yaml +++ b/swagger.yaml @@ -1,6 +1,6 @@ openapi: 3.0.0 info: - version: "0.1.15" + version: "0.1.16" title: Blockfrost.io ~ API Documentation x-logo: url: https://staging.blockfrost.io/images/logo.svg From 5b38d298bb9d74f4a2372bf092075fbd8bab2fcb Mon Sep 17 00:00:00 2001 From: 1000101 Date: Tue, 25 May 2021 20:19:54 +0200 Subject: [PATCH 2/2] fix/feat(docs): rate limiting --- CHANGELOG.md | 6 ++++++ swagger.yaml | 11 ++++++++--- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 2e08ffd1..4e520b3e 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -12,9 +12,15 @@ and this project will adhere to [Semantic Versioning](https://semver.org/spec/v2 - `/accounts/{stake_address}/addresses/assets` endpoint to list all assets on addresses related to a given stake_address (account) - `/epochs/latest/parameters` and `/blocks/latest/txs` endpoints to list the current information about latest epoch and block +### Changed + +- implementation (increase allowed burst) of rate limiting and clarified documentation + ### Fixed - `onchain_metadata` in `/assets/{asset}/total` endpoint that could have been missing in some special cases +- `onchain_metadata` in `/assets/:asset` endpoint to return null on malformed data which do not follow https://github.com/cardano-foundation/CIPs/pull/85/files + ## [0.1.15] - 2021-05-19 diff --git a/swagger.yaml b/swagger.yaml index dbb7037e..c5b778e6 100644 --- a/swagger.yaml +++ b/swagger.yaml @@ -74,9 +74,14 @@ info: ``` ## Limits - There are two types of limits we are enforcing. The first depends on your plan and is the number of request we allow per day. We defined - the day from midnight to midnight of UTC time. The second is rate limiting, where we limit an end user to 10 requests per second after a period - of 5 second burst. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and + There are two types of limits we are enforcing: + + The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. + + The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow + each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another + whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attemtps to make a call 3 seconds after whole burst, 30 requests will be processed. + We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. servers: