After talking to @r-marques and @libscott:
- A vote's id is currently generated by RethinkDB
- To verify a vote, the signature and the pubkey should be used
- Vote's id will be removed from the "external" vote model in the
future
- Nobody would want to retrieve a vote, but rather a vote by block
In case of the HTTP API, this means that a /votes/vote_id endpoint is
not feasible to implement.
It didn't feel good letting users retrieve also invalid or undecided
blocks in the /blocks/{block_id} endpoint.
Hence, now a block can be evaluated by it's status.
If block_id and status do not match, a 404 Not Found HTTP status code is
returned.
Per default, status is set to valid only.
- owner_afters --> owners_after
- List choices for operation query string
- List choices for fields query string
- Use proper sphinx-way to define type of query string
Inevitably, some resources will not allow to filter by the exact
keyword that is included in a resources body.
Take for example asset and metadata.
They both have a property called 'id', hence requests of a form:
/transactions&fields=x,y&property_name=z
might now be allowed to be resolved as the keyword 'id' in this
case could reference both 'metadata.id' and 'asset.id'.
This problem cannot be structurally resolved with URL paths.
Hence it was decided to emphasize on a few resources that
implement 'id' as a sort-of primary key.
A transaction contains:
- conditions
- fulfillments
- assets
- meta data
While:
- assets; and
- meta data
could be viewed as their own "tables" or resources, conditions
and fulfillments cannot. Why?
Because in comparison they do not contain a primary key, allowing
them to be queried by it.
