-
androlo authored0050e4ec
Eris DB web APIs (draft)
for eris-db version 0.11.x
Eris DB allows remote access to its functionality over http and websocket. It currently supports JSON-RPC 2.0, and REST-like http. There is also javascript bindings available in the erisdb-js library.
TOC
- HTTP Requests
- JSON-RPC 2.0
- REST-like HTTP
- Common objects and formatting
- Event-system
- Methods
- NameReg
- Filters
HTTP Requests
The only data format supported is JSON. All post requests needs to use Content-Type: application/json
. The charset flag is not supported (json is utf-8 encoded by default).
JSON RPC 2.0
The default endpoints for JSON-RPC (2.0) is /rpc
for http based, and /socketrpc
for websocket. The namespace for the JSON-RPC service is erisdb
.
It does not yet support notifications or batched requests.
Objects
Errors
PARSE_ERROR = -32700
INVALID_REQUEST = -32600
METHOD_NOT_FOUND = -32601
INVALID_PARAMS = -32602
INTERNAL_ERROR = -32603
#####Request
{
jsonrpc: <string>
method: <string>
params: <Object>
id: <string>
}
#####Response
{
jsonrpc: <string>
id: <string>
result: <Object>
error: <Error>
}
#####Error
{
code: <number>
message: <string>
}
Id can be any string value. Parameters are named, and wrapped in objects. Also, params, result and error params may be null
.
#####Example
Request:
{
jsonrpc: "2.0",
method: "erisdb.getAccount",
params: {address: "37236DF251AB70022B1DA351F08A20FB52443E37"},
id="25"
}
Response:
{
address: "37236DF251AB70022B1DA351F08A20FB52443E37",
pub_key: null,
sequence: 0,
balance: 110000000000,
code: "",
storage_root: ""
}
REST-like HTTP
The REST-like API provides the typical endpoint structure i.e. endpoints are named as resources, parameters can be put in the path, and queries are used for filtering and such. It is not fully compatible with REST; partly because some GET requests can contain sizable input so POST is used instead. There are also some modeling issues but those will most likely be resolved before version 1.0.
##Common objects and formatting
This section contains some common objects and explanations of how they work.
###Numbers and strings
Numbers are always numbers, and never strings. This is different from Ethereum where currency values are so high they need string representations. The only thing hex strings are used for is to represent byte arrays.
Hex strings are never prefixed.
#####Examples
"some_number_field" : 5892,
"another_number_field" : 0x52
"hex_string" : "37236DF251AB70022B1DA351F08A20FB52443E37"
###Keys and addresses
Public and Private keys in JSON data are either null, or on the form: [type, hex]
, where type
is the public, or private key type, and hex
is the hex-string representation of the key bytes.
- A
public address
is a 20 byte hex string. - A
public key
is a 32 byte hex string. - A
private key
is a 64 byte hex string.
#####WARNING
When using a client-server setup, do NOT send public keys over non-secure connections. The only time this is fine is during development when the keys are nothing but test data and does not protect anything of value. Normally they should either be kept locally and used to sign transactions locally, held on the server where the blockchain client is running, or be passed over secure channels.
#####Examples
A public address: "37236DF251AB70022B1DA351F08A20FB52443E37"
The corresponding Ed25519 public key: [1, "CB3688B7561D488A2A4834E1AEE9398BEF94844D8BDBBCA980C11E3654A45906"]
The corresponding Ed25519 private key: [1, "6B72D45EB65F619F11CE580C8CAED9E0BADC774E9C9C334687A65DCBAD2C4151CB3688B7561D488A2A4834E1AEE9398BEF94844D8BDBBCA980C11E3654A45906"]
These are the types of transactions. Note that in DApp programming you would only use the CallTx
, and maybe NameTx
.
####SendTx
{
inputs: [<TxInput>]
outputs: [<TxOutput>]
}
####CallTx
{
input: <TxInput>
address: <string>
gas_limit: <number>
fee: <number>
data: <string>
}
####NameTx
{
input: <TxInput>
name: <string>
data: <string>
amount: <number>
fee: <number>
}
####BondTx
{
pub_key: <PubKey>
signature: <string>
inputs: [<TxInput>]
unbond_to: [<TxOutput>]
}
####UnbondTx
{
address: <string>
height: <number>
signature: <string>
}
####RebondTx
{
address: <string>
height: <number>
signature: <string>
}
####DupeoutTx
{
address: <string>
vote_a: <Vote>
vote_b: <Vote>
}
These are the support types that are referenced in the transactions:
####TxInput
{
address: <string>
amount: <number>
sequence: <number>
signature: <string>
pub_key: <string>
}
####TxOutput
{
address: <string>
amount: <number>
}
####Vote
{
height: <number>
type: <number>
block_hash: <string>
block_parts: {
total: <number>
hash: <string>
}
signature: <string>
}
Tendermint events can be subscribed to regardless of what connection type is used. There are three methods for this:
-
EventSubscribe is used to subscribe to a given event, using an event-id string as argument. The response will contain a
subscription ID
, which can be used to close down the subscription later, or poll for new events if using HTTP. More on event-ids below. -
EventUnsubscribe is used to unsubscribe to an event. It requires you to pass the
subscription ID
as an argument. -
EventPoll is used to get all the events that has accumulated since the last time the subscription was polled. It takes the
subscription ID
as a parameter. NOTE: This only works over HTTP. Websocket connections will automatically receive events as they happen. They are sent as regular JSON-RPC 2.0 responses with thesubscriber ID
as response id.
There is another slight difference between polling and websocket, and that is the data you receive. If using sockets, it will always be one event at a time, whereas polling will give you an array of events.
Event types
These are the type of events you can subscribe to.
The "Account" events are triggered when someone transacts with the given account, and can be used to keep track of account activity.
NewBlock and Fork happens when a new block is committed or a fork happens, respectively.
The other events are directly related to consensus. You can find out more about the Tendermint consensus system in the Tendermint white paper. There is also information in the consensus sources, although a normal user would not be concerned with the consensus mechanisms, but would mostly just listen to account- and perhaps block-events.
Account Input
This notifies you when an account is receiving input.
Event ID: Acc/<address>/Input
Example: Acc/B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7/Input
will subscribe to input events from the account with address: B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7.
Event object:
{
tx: <Tx>
return: <string>
exception: <string>
}
Account Output
This notifies you when an account is yielding output.
Event ID: Acc/<address>/Output
Example: Acc/B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7/Output
will subscribe to output events from the account with address: B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7.
Event object:
<Tx>
Account Call
This notifies you when an account is the target of a call. This event is emitted when CallTx
s (transactions) that target the given account has been finalized. It is possible to listen to this event when creating new contracts as well; it will fire when the transaction is committed (or not, in which case the 'exception' field will explain why it failed).
NOTE: The naming here is a bit unfortunate. Ethereum uses 'transaction' for (state-changing) transactions to a contract account, and 'call' for read-only calls like is used for accessor functions and such. Tendermint on the other hand, which uses many types of transactions uses 'CallTx' for a transaction made to a contract account, since it calls the code in that contract, and refers to these simply as 'calls'. Read-only calls is normally referred to as 'simulated calls'.
Event ID: Acc/<address>/Call
Example: Acc/B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7/Call
will subscribe to events from the account with address: B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7.
{
call_data: {
caller: <string>
callee: <string>
data: <string>
value: <number>
gas: <number>
}
origin: <string>
tx_id: <string>
return: <string>
exception: <string>
}
Log
This notifies you when the VM fires a log-event. This happens for example when a solidity event is fired.
Event ID: Log/<address>
Example: Log/B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7/Input
will subscribe to all log events from the account with address: B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7.
type Log struct { Address Word256 Topics []Word256 Data []byte Height uint64 }
Event object:
{
address: <string>
topics: []<string>
data: <string>
height <number>
}
address
is the address of the account that created the log event.
topics
is the parameters listed as topics. In a (named) Solidity event they would be the hash of the event name, followed by each param with the indexed
modifier.
data
the data. In a Solidity event these would be the params without the indexed
modifier.
height
is the current block-height.
New Block
This notifies you when a new block is committed.
Event ID: NewBlock
Event object:
<Block>
Fork
This notifies you when a fork event happens.
Event ID: Fork
Event object:
TODO
<Block>
Bond
This notifies you when a bond event happens.
Event ID: Bond
Event object:
<Tx>
Unbond
This notifies you when an unbond event happens.
Event ID: Unbond
Event object:
<Tx>
Rebond
This notifies you when a rebond event happens.
Event ID: Rebond
Event object:
<Tx>
Dupeout
This notifies you when a dupeout event happens.
Event ID: Dupeout
Event object:
<Tx>
The name-registry is a built-in key-value store that allow you to store bulk data in a different storage. It is currently regulated by the use of Tendermint tokens. The cost of storing some Data
in the name-registry is this:
TotalCost = Cost*NumberOfBlocks
Cost = CostPerBlock*CostPerByte*(length(Data) + 32)
CostPerBlock = 1
CostPerByte = 1
length(Data) = the number of bytes in 'Data'.
To pay this cost you use the amount
field in the namereg transaction. If you want to store a 3 kb document for 10 blocks, the total cost would be 1*1*(3000 + 32)*10 = 30320
tendermint tokens.
See the TransactNameReg method for more info about adding entries to the name-registry, and the methods in the Name-registry for accessing them.
###Accounts
Name | RPC method name | HTTP method | HTTP endpoint |
---|---|---|---|
GetAccounts | erisdb.getAccounts | GET | /accounts |
GetAccount | erisdb.getAccount | GET | /accounts/:address |
GetStorage | erisdb.getStorage | GET | /accounts/:address/storage |
GetStorageAt | erisdb.getStorageAt | GET | /accounts/:address/storage/:key |
###Blockchain
Name | RPC method name | HTTP method | HTTP endpoint |
---|---|---|---|
GetBlockchainInfo | erisdb.getBlockchainInfo | GET | /blockchain |
GetChainId | erisdb.getChainId | GET | /blockchain/chain_id |
GetGenesisHash | erisdb.getGenesisHash | GET | /blockchain/genesis_hash |
GetLatestBlockHeight | erisdb.getLatestBlockHeight | GET | /blockchain/latest_block/height |
GetLatestBlock | erisdb.getLatestBlock | GET | /blockchain/latest_block |
GetBlocks | erisdb.getBlocks | GET | /blockchain/blocks |
GetBlock | erisdb.getBlock | GET | /blockchain/blocks/:height |
###Consensus
Name | RPC method name | HTTP method | HTTP endpoint |
---|---|---|---|
GetConsensusState | erisdb.getConsensusState | GET | /consensus |
GetValidators | erisdb.getValidators | GET | /consensus/validators |
###Events
Name | RPC method name | HTTP method | HTTP endpoint |
---|---|---|---|
EventSubscribe | erisdb.eventSubscribe | POST | /event_subs |
EventUnsubscribe | erisdb.eventUnsubscribe | DELETE | /event_subs/:id |
EventPoll | erisdb.eventPoll | GET | /event_subs/:id |
###Name-registry
Name | RPC method name | HTTP method | HTTP endpoint |
---|---|---|---|
GetNameRegEntry | erisdb.getNameRegEntry | GET | /namereg/:key |
GetNameRegEntries | erisdb.getNameRegEntries | GET | /namereg |
###Network
Name | RPC method name | HTTP method | HTTP endpoint |
---|---|---|---|
GetNetworkInfo | erisdb.getNetworkInfo | GET | /network |
GetClientVersion | erisdb.getClientVersion | GET | /network/client_version |
GetMoniker | erisdb.getMoniker | GET | /network/moniker |
IsListening | erisdb.isListening | GET | /network/listening |
GetListeners | erisdb.getListeners | GET | /network/listeners |
GetPeers | erisdb.getPeers | GET | /network/peers |
GetPeer | erisdb.getPeer | GET | /network/peer/:address |
NOTE: Get peer is not fully implemented.
###Transactions
Name | RPC method name | HTTP method | HTTP endpoint |
---|---|---|---|
BroadcastTx | erisdb.broadcastTx | POST | /txpool |
GetUnconfirmedTxs | erisdb.getUnconfirmedTxs | GET | /txpool |
###Code execution
Name | RPC method name | HTTP method | HTTP endpoint |
---|---|---|---|
Call | erisdb.call | POST | /calls |
CallCode | erisdb.callCode | POST | /codecalls |
####Unsafe
Name | RPC method name | HTTP method | HTTP endpoint |
---|---|---|---|
Transact | erisdb.transact | POST | /unsafe/txpool |
Transact | erisdb.transactAndHold | POST | /unsafe/txpool?hold=true |
TransactNameReg | erisdb.transactNameReg | POST | /unsafe/namereg/txpool |
GenPrivAccount | erisdb.genPrivAccount | GET | /unsafe/pa_generator |
Here are the catagories.
- Accounts
- BlockChain
- Consensus
- Events
- Name-registry
- Network
- Transactions
- Code Execution (calls)
- Unsafe
In the case of JSON-RPC, the parameters are wrapped in a request object, and the return value is wrapped in a response object.
In the case of REST-like HTTP GET requests, the params (and query) is provided in the url. If it's a POST, PATCH or PUT request, the parameter object should be written to the body of the request as JSON. It is normally the same params object as in JSON-RPC.
Unsafe is methods that require a private key to be sent either to or from the client, and should therefore be used only during development/testing, or with extreme care. They may be phased out entirely.
Get accounts will return a list of accounts. If no filtering is used, it will return all existing accounts.
#####HTTP
Method: GET
Endpoint: /accounts
#####JSON-RPC
Method: erisdb.getAccounts
Parameter:
{
filters: [<FilterData>]
}
Filters
Field | Underlying type | Ops | Example Queries |
---|---|---|---|
balance |
uint64 |
< , > , <= , >= , ==
|
q=balance:<=11 |
code |
byte[] |
== , !=
|
q=code:1FA872 |
#####Return value
{
accounts: [<Account>]
}
#####Additional info
See GetAccount below for more info on the Account
object.
See the section on Filters for info on the FilterData
object.
Get an account by its address.
#####HTTP
Method: GET
Endpoint: /accounts/:address
Params: The public address
as a hex string.
#####JSON-RPC
Method: erisdb.getAccount
Parameter:
{
address: <string>
}
#####Return value
{
address: <string>
pub_key: <PubKey>
sequence: <number>
balance: <number>
code: <string>
storage_root: <string>
}
address
is a public address.
pub_key
is a public key.
#####Additional info
Sequence is sometimes referred to as the "nonce".
There are two types of objects used to represent accounts, one is public accounts (like the one here), the other is private accounts, which only holds information about an accounts address, public and private key.
Get the complete storage of a contract account. Non-contract accounts has no storage.
NOTE: This is mainly used for debugging. In most cases the storage of an account would be accessed via public accessor functions defined in the contracts ABI.
#####HTTP
Method: GET
Endpoint: /accounts/:address/storage
Params: The public address
as a hex string.
#####JSON-RPC
Method: erisdb.getStorage
Parameter:
{
address: <string>
}
#####Return value
{
storage_root: <string>
storage_items: [<StorageItem>]
}
storage_root
is a public address.
See GetStorageAt
below for more info on the StorageItem
object.
Get a particular entry in the storage of a contract account. Non-contract accounts has no storage.
NOTE: This is mainly used for debugging. In most cases the storage of an account would be accessed via public accessor functions defined in the contracts ABI.
#####HTTP
Method: GET
Endpoint: /accounts/:address/storage/:key
Params: The public address
as a hex string, and the key
as a hex string.
#####JSON-RPC
Method: erisdb.getStorageAt
Parameter:
{
address: <string>
key: <string>
}
#####Return value
{
key: <string>
value: <string>
}
Both key
and value
are hex strings.
Get the current state of the blockchain. This includes things like chain-id and latest block height. There are individual getters for all fields as well.
#####HTTP
Method: GET
Endpoint: /blockchain
#####JSON-RPC
Method: erisdb.getBlockchainInfo
Parameter: -
#####Return value
{
chain_id: <string>
genesis_hash: <string>
latest_block: <BlockMeta>
latest_block_height: <number>
}
#####Additional info
chain_id
is the name of the chain.
genesis_hash
is a 32 byte hex-string. It is the hash of the genesis block, which is the first block on the chain.
latest_block
contains block metadata for the latest block. See the GetBlock method for more info.
latest_block_height
is the height of the latest block, and thus also the height of the entire chain.
The block height is sometimes referred to as the block number.
See GetBlock for more info on the BlockMeta
type.
Get the chain id.
#####HTTP
Method: GET
Endpoint: /blockchain/chain_id
#####JSON-RPC
Method: erisdb.getChainId
Parameter: -
#####Return value
{
chain_id: <string>
}
Get the genesis hash. This is a 32 byte hex-string representation of the hash of the genesis block. The genesis block is the first block on the chain.
#####HTTP
Method: GET
Endpoint: /blockchain/genesis_hash
#####JSON-RPC
Method: erisdb.getGenesisHash
Parameter: -
#####Return value
{
genesis_hash: <string>
}
Get the height of the latest block. This would also be the height of the entire chain.
#####HTTP
Method: GET
Endpoint: /blockchain/latest_block/height
#####JSON-RPC
Method: erisdb.getLatestBlockHeight
Parameter: -
#####Return value
{
latest_block_height: <number>
}
Gets the block that was added to the chain most recently.
#####HTTP
Method: GET
Endpoint: /blockchain/latest_block
#####JSON-RPC
Method: erisdb.getLatestBlock
Parameter: -
#####Return value
{
latest_block: <BlockMeta>
}
#####Additional info
See GetBlock for more info on the BlockMeta
type.
Get a series of blocks from the chain.
#####HTTP
Method: GET
Endpoint: /blockchain/blocks
#####JSON-RPC
Method: erisdb.getBlocks
Parameter:
{
filters: [<FilterData>]
}
Filters
Field | Underlying type | Ops | Example Queries |
---|---|---|---|
height |
uint |
< , > , <= , >= , ==
|
q=height:>4 , q=height:10..*
|
#####Return value
{
min_height: <number>
max_height: <number>
block_metas: [<BlockMeta>]
}
The BlockMeta
object:
{
hash: <string>
header: {
chain_id: <string>
height: <number>
time: <string>
fees: <number>
num_txs: <number>
last_block_hash: <string>
last_block_parts: {
total: <number>
hash: <string>
}
state_hash: <string>
}
parts: {
total: <number>
hash: <string>
}
}
#####Additional info
TODO
See the section on Filters for info on the FilterData
object.
min_height
and max_height
is the two actual values used for min and max height when fetching the blocks. The reason they are included is because the heights might have been modified, like for example when the blockchain height is lower then the max height provided in the query.
See GetBlock for more info on the BlockMeta
type.
Get the block at the given height.
#####HTTP
Method: GET
Endpoint: /blockchain/block/:number
#####JSON-RPC
Method: erisdb.getBlock
Parameter:
{
height: <number>
}
#####Return value
{
header: {
chain_id: <string>
height: <number>
time: <string>
fees: <number>
num_txs: <number>
last_block_hash: <string>
last_block_parts: {
total: <number>
hash: <string>
}
state_hash: <string>
}
validation: {
commits: [<Commit>]
TODO those other two.
}
data: {
txs: [<Tx>]
TODO that other field.
}
}
The Commit
object:
{
address: <string>
round: <number>
signature: <string>
}
#####Additional info
TODO
See The transaction types for more info on the Tx
types.
Get the current consensus state.
#####HTTP
Method: GET
Endpoint: /consensus
#####JSON-RPC
Method: erisdb.getConsensusState
Parameter: -
#####Return value
{
height: <number>
round: <number>
step: <number>
start_time: <string>
commit_time: <string>
validators: [<Validator>]
proposal: {
height: <number>
round: <number>
block_parts: {
total: <number>
hash: <string>
}
pol_parts: {
total: <number>
hash: <string>
}
signature: <string>
}
}
#####Additional info
TODO
See the GetValidators method right below for info about the Validator
object.
Get the validators.
#####HTTP
Method: GET
Endpoint: /consensus/validators
#####JSON-RPC
Method: erisdb.getValidators
Parameter: -
#####Return value
{
block_height: <number>
bonded_validators: [<Validator>]
unbonding_validators: [<Validator>]
}
The Validator
object:
{
address: <string>
pub_key: <PubKey>
bon_height: <number>
unbond_height: <number>
last_commit_height: <number>
voting_power: <number>
accum: <number>
}
#####Additional info
TODO
Subscribe to a given type of event.
#####HTTP
Method: POST
Endpoint: /event_subs/
Body: See JSON-RPC parameter.
#####JSON-RPC
Method: erisdb.eventSubscribe
Parameter:
{
event_id: <string>
}
#####Return value
{
sub_id: <string>
}
#####Additional info
For more information about events and the event system, see the Event system section.
Unsubscribe to an event type.
#####HTTP
Method: DELETE
Endpoint: /event_subs/:id
#####JSON-RPC
Method: erisdb.eventUnsubscribe
Parameter: -
#####Return value
{
result: <bool>
}
#####Additional info
For more information about events and the event system, see the Event system section.
Poll a subscription. Note this cannot be done if using websockets, because then the events will be passed automatically over the socket.
#####HTTP
Method: GET
Endpoint: /event_subs/:id
#####JSON-RPC
Method: erisdb.eventPoll
#####Return value
{
events: [<Event>]
}
#####Additional info
For more information about events and the event system, see the Event system section. This includes info about the Event
object.
This will return a list of name reg entries. Filters may be used.
#####HTTP
Method: GET