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.
According to: https://www.ietf.org/rfc/rfc2616.txt a 303 See Other can
be returned to indicate that the resource the user is looking for can be
found under a new path.
In the case of a transaction including the `status == 'valid'`, we
return 303 See Other, as well as a Location header to the /transactions
endpoint.
"The response to the request can be found under a different URI and SHOULD be
retrieved using a GET method on that resource."
According to https://www.ietf.org/rfc/rfc2616.txt a 201 Created status
code MUST only be returned when:
"The origin server MUST create the resource before returning the 201 status
code."
hence, a 202 Accepted's definition is more appropriate:
"The request has been accepted for processing, but the processing has not been
completed.
The entity returned with this response SHOULD include an indication of the
request's current status and either a pointer to a status monitor or some
estimate of when the user can expect the request to be fulfilled."
* Added replicaset name to bigchaindb config
* changed travis replSet to match bigchaindb default
* Updated initialize_replica_set
It now initializes the replica set with the name provided by the
bigchaindb config file.
* initialize_replica_set is now called when creating a mongodb connection.
This way we are sure that a replica set exists when we return a
connection.
* Moved the initialize replica set logic to the connection.
* update the config documentation
