Added a /rest/blockhash/.json endpoint, so that the user can fetch a block hash by height via REST (analogous to the ‘getblockhash’ RPC method).
For someone wanting to gather block or header data via REST only, there was no way to begin fetching blocks/headers at specific heights without knowing the block hashes at those heights. This endpoint might also come in handy for someone wanting to quickly verify a block existing at a specific height in the active chain.
Nice. Thanks for contributing. Concept ACK.
What holds you back in completing this with supporting hex/bin? Should be trivial.
@jonasschnelli Yeah I noticed the hex/bin pattern but wasn’t entirely sure if I should use those here too. I suppose I wasn’t sure exactly what should be serialized in this case, as the other endpoints using bin/hex are serializing whole class/struct instances like CBlockHeader or CBlock, whereas this is a simple hash string. I can certainly add that support.
Thanks for taking a look!
@aaron-hanson. You can just create a data stream and push the hashes onto the stream. A rest client could save ~50% brutto bandwidth over a JSON/hexstring.
0CDataStream ssFooBar(SER_NETWORK, PROTOCOL_VERSION);
1ssGetUTXOResponse << pindex->GetBlockHash();
Concept ACK. I agree it should be possible to query block by height.
There are only tests for successful calls. IMHO there should be tests for the errors too:
RESTERR(req, HTTP_BAD_REQUEST, "Parse error");RESTERR(req, HTTP_BAD_REQUEST, "Block height out of range: " + strHeight).Another option would be to overload /rest/block/[hash|height].[bin,hex.json]. Note that json response includes the hash.
300+ CDataStream ssGetBlockHashResponse(SER_NETWORK, PROTOCOL_VERSION);
301+ ssGetBlockHashResponse << pindex->GetBlockHash();
302+ std::string strHex = HexStr(ssGetBlockHashResponse.begin(), ssGetBlockHashResponse.end()) + "\n";
303+
304+ req->WriteHeader("Content-Type", "text/plain");
305+ req->WriteReply(HTTP_OK, strHex);
req->WriteReply(HTTP_OK, pindex->GetBlockHash()->GetHex());?
Another option would be to overload /rest/block/[hash|height].[bin,hex.json]. Note that json response includes the hash. @promag - I thought about this too… After researching a bit I found an older issue (#6011) about essentially the same thing, but in RPC. I assumed from the opinions there that I should probably just add this blockhash endpoint and not overload the block endpoint.
As others say in #6011, it was possible to query block by height but with 2 calls. With REST call there is no way unless you walk back from the tip. Unless we want to mirror the RPC interface, I think overloading sounds cooler.
In that scenario, the difference between the 2 endpoints would be cache headers, since by hash the block is immutable but not by height (at least near the tip).
312+ req->WriteHeader("Content-Type", "application/json");
313+ req->WriteReply(HTTP_OK, strJSON);
314+ return true;
315+ }
316+ default: {
317+ return RESTERR(req, HTTP_NOT_FOUND, "output format not found (available: json)");
@aaron-hanson - are you still working on this? It needs rebasing and squashing.
Suggest we close with ‘up for grabs’ if there’s no activity on this PR soon.
Added a /rest/blockhash/<HEIGHT>.<bin|hex|json> endpoint, so that the user can fetch a block hash by height via REST (analogous to the 'getblockhash' RPC method).
287+ const CBlockIndex *pindex = chainActive[nHeight];
288+
289+ switch (rf) {
290+ case RetFormat::BINARY: {
291+ CDataStream ssGetBlockHashResponse(SER_NETWORK, PROTOCOL_VERSION);
292+ ssGetBlockHashResponse << pindex->GetBlockHash();
pindex->GetBlockHash() be refactored out of the switch statement, both to reduce code repetition and to minimise the scope of where cs_main is held?
222@@ -223,6 +223,56 @@ def run_test(self):
223 self.nodes[0].generate(1) #generate block to not affect upcoming tests
224 self.sync_all()
225
226+
Generally looks great. Thanks for the contribution and the good tests.
There are a few code style nits, which I haven’t commented on inline. Take a look at https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#coding-style. Notably:
(I realise that you were probably copying surrounding style, but new code should adhere to the style guildelines where possible.)
