@ -9,7 +9,7 @@ As of now the documentation is not hosted anywhere, but you can easily do it you
## Mock Up
## Mock Up
To use a mock up of the endpoints in the API run `./run.sh doc` (UI + mock up server) or `./run.sh mock` (only mock up server). You can play with the mocked up endpoints using the [web UI](http://localhost:8001), importing `swagger.yml` into Postman or using your preferred language and using `http://loclahost:4010` as base URL.
To use a mock up of the endpoints in the API run `./run.sh doc` (UI + mock up server) or `./run.sh mock` (only mock up server). You can play with the mocked up endpoints using the [web UI](http://localhost:8001), importing `swagger.yml` into Postman or using your preferred language and using `http://localhost:4010` as base URL.
All the endpoints that return a list of undefined size use pagination. Unless the opposite is explicitly said.
All the endpoints that return a list of undefined size use pagination. Unless the opposite is explicitly said.
In order to use pagination, three query parameters are used:
In order to use pagination, three query parameters are used:
* `fromItem`:indicates the first item to be returned. In general, this parameter shouldn't be provided in the first call to the endpoint, and use the `itemId` of the last returned item (+/-) 1, if the order is (ascending/descending).
* `fromItem`:indicates the first item to be returned. In general, this parameter shouldn't be provided in the first call to the endpoint, and use the `itemId` of the last returned item (+/-) 1, if the order is (ascending/descending).
* `order`:all pginated items are ordered chronologicaly. However the specific fields to guarantee this order depend on each endpoint. For this purpose, `itemId` is used (itemId follows ascending chronological order except for unforged L1 user transactions). If the parameter is not provided, ascending order will be used by default.
* `limit`:maximum amount of items to include in each response. Default is 20, maximum 2049.
* `order`:all paginated items are ordered chronologicaly. However the specific fields to guarantee this order depend on each endpoint. For this purpose, `itemId` is used (itemId follows ascending chronological order except for unforged L1 user transactions). If the parameter is not provided, ascending order will be used by default.
* `limit`:maximum amount of items to include in each response. Default is 20, maximum is 2049.
Responses for those endpoint will always include a `pendingItems` property. This property includes the amount of items that are not fetched yet. his can be used to:
Responses for those endpoints will always include a `pendingItems` property. This property includes the amount of items that are not fetched yet. This can be used to:
* Calculate the amount of items that match the filters:`totalItems = length(alreadyFetchedItems) + pendingItems`
* Calculate the amount of items that match the filters:`totalItems = length(alreadyFetchedItems) + pendingItems`
* Know when all items have been fetched:`if pendingItems == 0 {/* all items have been fetched */}`
* Know when all items have been fetched:`if pendingItems == 0 {/* all items have been fetched */}`
@ -29,7 +29,7 @@ info:
### Signatures
### Signatures
The POST endpoint require to be signed using BabyJubJub or Ethereum keys. TODO:add references to libraries / examples / ...
The POST endpoint requires to be signed using BabyJubJub or Ethereum keys. TODO:add references to libraries / examples / ...
version:"0.0.1"
version:"0.0.1"
title:Hermez Network API
title:Hermez Network API
@ -70,7 +70,7 @@ paths:
- Account
- Account
summary:Send an authorization that will allow the coordinator to register accounts associated to an Ethereum address on behalf of the user.
summary:Send an authorization that will allow the coordinator to register accounts associated to an Ethereum address on behalf of the user.
description:>-
description:>-
Send an authorization to create rollup accounts associated to an Ethereum address. Each account creation (an account can only hold a specific token) is effective once the coordinator forges the corresponding L1CoordinatorTx (which are always of type *account creation*).
Send an authorization to create rollup accounts associated to an Ethereum address. Each account creation (an account can only hold a specific token) is effective once the coordinator forges the corresponding L1CoordinatorTx (which is always of type *account creation*).
operationId:postRegister
operationId:postRegister
requestBody:
requestBody:
description:Account creation authorization.
description:Account creation authorization.
@ -392,7 +392,7 @@ paths:
post:
post:
tags:
tags:
- Transaction
- Transaction
summary:Add an L2 transaction to the coordinator's pool
summary:Add an L2 transaction to the coordinator's pool.
description:>-
description:>-
Send L2 transaction. The transaction will be stored in the transaction pool of the coordinator and eventually forged.
Send L2 transaction. The transaction will be stored in the transaction pool of the coordinator and eventually forged.
operationId:postTx
operationId:postTx
@ -727,7 +727,7 @@ paths:
get:
get:
tags:
tags:
- Hermez status
- Hermez status
summary:Get a full batch
summary:Get a full batch.
description:>-
description:>-
Get a specific batch, including the associated transactions. The object returned in this method can be a bit heavy.
Get a specific batch, including the associated transactions. The object returned in this method can be a bit heavy.
If you're devloping a front end, you may consider using a combinaton of `GET /batches/{batchnum}` and `GET /history-transactions?batchNum={batchNum}`.
If you're devloping a front end, you may consider using a combinaton of `GET /batches/{batchnum}` and `GET /history-transactions?batchNum={batchNum}`.
ToniRamirezM
3 years ago