Add /rest/headers/<count>/<hash>.<ext> #5444

pull sipa wants to merge 1 commits into bitcoin:master from sipa:restheader changing 2 files +99 −14

sipa commented at 12:45 PM on December 8, 2014: member

Add support for requesting headers in binary or hexadecimal format. This is faster than requesting full blocks.

No JSON format defined for now, and I'm not sure whether we need one.
jgarzik commented at 1:01 PM on December 8, 2014: contributor

Code looks good to me.

However, it's still a lot of HTTP overhead, even with keep-alive, to request one header per HTTP request. /rest/headers/ seems more appropriate, a la 'getutxos'.

Suggestion: GET /rest/headers/$hash.ext gets 2000 headers, unless a "?limit=N" qualifier is added.
sipa commented at 1:06 PM on December 8, 2014: member

@jgarzik Good idea. This was just some random thought that could be useful; I'll change it.
jonasschnelli commented at 1:46 PM on December 8, 2014: contributor
1. The 2000 headers per request/response seems to be a good idea. I'm not sure about the limit parameter per query string. It might end up in different parameter injection. getutxos uses raw post data. /rest/headers/notxdetails/ uses flag/parameter in the URL?
Would /rest/headers/limit/2000/<hash>.ext be a overkill?

But maybe the query string parameter is more clear.
1. Is there a reason for no JSON support? If it's just your time/priority I will add it afterwards.

in src/rest.cpp:None in 176371c7ee outdated

 109 | +            throw RESTERR(HTTP_NOT_FOUND, hashStr + " not found");
 110 | +        header = mapBlockIndex[hash]->GetBlockHeader();
 111 | +    }
 112 | +
 113 | +    CDataStream ssHeader(SER_NETWORK, PROTOCOL_VERSION);
 114 | +    ssBlock << header;

jonasschnelli commented at 7:09 PM on December 8, 2014:

shouldn't ssBlock be ssHeader?

in src/rest.cpp:None in 176371c7ee outdated

 114 | +    ssBlock << header;
 115 | +
 116 | +    switch (rf) {
 117 | +    case RF_BINARY: {
 118 | +        string binaryHeader = ssHeader.str();
 119 | +        conn->stream() << HTTPReplyHeader(HTTP_OK, fRun, binaryBlock.size(), "application/octet-stream") << binaryBlock << std::flush;

jonasschnelli commented at 7:09 PM on December 8, 2014:

shouldn't binaryBlock be ssBlock?

laanwj commented at 8:57 AM on December 9, 2014: member
- Concept looks good to me
- I agree we don't really need a JSON format. If the purpose for this is to be a low-overhead API, we should stay away from JSON
- As for parameters (such as start, limit), for a REST interface I'd prefer them to be all to be part of the query path instead of introducing ?= parameters. ?= parameters are non-canonical in that they can be provided in any order, which introduces a kind of aliasing that messes with caching
jonasschnelli commented at 12:25 PM on December 9, 2014: contributor

Regarding JSON: Is there a reason to not support JSON? I think there are many potential REST users using script programming languages like Python or PHP. The unpacking of the byte array is somehow annoying in these languages and people might tend to have a overhead in the information transmission protocol (TCP/HTTP/JSON in this case) and save some development effort. We could even say HTTP is a overhead (because its plaintext and line based). Then we would end up in a raw TCP socket and might be very close to the P2P protocol. IMO we should distinct both "APIs".

I would find it a bad idea to have a potential JSON output format which does not support all possible methods.

A feasible step would to drop JSON support completely for the REST API. But we might have to come out of our byte-optimized-land and see what others expect from a API.
laanwj commented at 12:50 PM on December 9, 2014: member

Packing/unpacking byte arrays is well-supported in Python, I do that all the time, that's a bit of a strawman. See also https://github.com/petertodd/python-bitcoinlib .

Anyhow: headers have a well-defined format, and for hashing and such you really need the canonical, raw data. A "cooked" version would be much less useful. It could be added later but I doubt there is actual demand for it.
sipa force-pushed on Dec 9, 2014
sipa commented at 3:52 PM on December 9, 2014: member

Updated.
sipa renamed this:
~~Add /rest/header~~
Add /rest/headers/<count>/<hash>.<ext>
on Dec 9, 2014
jonasschnelli commented at 10:10 AM on December 12, 2014: contributor

needs rebase
jonasschnelli commented at 10:49 AM on December 12, 2014: contributor

tested (rebase is trivial).

ACK
Add /rest/headers f676c80f43
sipa force-pushed on Dec 12, 2014
laanwj added the label Improvement on Dec 16, 2014
laanwj added the label RPC on Dec 16, 2014
laanwj merged this on Dec 16, 2014
laanwj closed this on Dec 16, 2014
laanwj referenced this in commit 103f66bf82 on Dec 16, 2014
0xartem referenced this in commit ad7f556a09 on Jun 1, 2018
MarcoFalke locked this on Sep 8, 2021

Contributors

Labels

Refactoring RPC/REST/ZMQ

Linked (view graph)

#6041 [REST] documentation update