[REST] JSON support for /rest/headers #5486

pull jonasschnelli wants to merge 1 commits into bitcoin:master from jonasschnelli:2014_12_rest_docu changing 4 files +51 −13

jonasschnelli commented at 11:01 AM on December 16, 2014: contributor

also includes REST documentation update for /rest/headers
jonasschnelli force-pushed on Dec 16, 2014
laanwj added the label REST on Jan 8, 2015
fanquake commented at 3:39 AM on March 26, 2015: member

Needs rebase
jonasschnelli force-pushed on Mar 26, 2015
jonasschnelli commented at 1:02 PM on March 26, 2015: contributor

Rebased. I still think it would make sense to merge this. At least it would add documentation for rest/getheaders (which currently is missing). I could also try to split of the documentation change for separate pull-in. The JSON support for getheaders would round off/complete the json/bin/hex output support.
jgarzik commented at 1:17 PM on March 26, 2015: contributor

Code appears correct... I just wonder who would use JSON header queries.
jonasschnelli commented at 1:41 PM on March 26, 2015: contributor

@jgarzik couldn't we ask the same for json blocks? I just think we should have consistent output support over all rest calls.
laanwj commented at 2:58 PM on March 26, 2015: member

Well at least blocks contain transactions. None of the information in headers is that useful in itself, and don't you get a similar view with /rest/block/notxdetails/?
jonasschnelli commented at 3:45 PM on March 26, 2015: contributor

IMO JSON output support is for users who don't like to deserialize data. /rest/block/notxdetails/ does not allow one to retrieve multiple blocks/headers at one time. Thats why there is a /rest/getheaders call. It looks somehow bad if we have only one rest call without JSON support and users there need to deserialize data (which mean the need a library or have to learn more about the protocol).
laanwj commented at 7:40 PM on March 26, 2015: member

Yes, I understand the purpose but I'm with @jgarzik in wondering why anyone would use this, as the header has very little informational value outside its (hashable, unmalleable) binary representation. But I'm not strongly against it either it's not a lot of code. And there's something to be said for consistency.
laanwj commented at 8:07 AM on March 27, 2015: member

utACK
paveljanik commented at 5:44 AM on April 16, 2015: contributor

ACK (I was about to add the missing /rest/headers documentation ;-)
jonasschnelli commented at 6:31 AM on April 16, 2015: contributor

Yes. This PR also includes the missing docs for already merged rest headers call (it's a separate commit).
laanwj commented at 4:53 PM on July 2, 2015: member

After #6247 this can use the existing BlockHeaderToJSON (see my comment about overlap there)
jonasschnelli force-pushed on Jul 2, 2015
jonasschnelli force-pushed on Jul 2, 2015
jonasschnelli force-pushed on Jul 2, 2015
jonasschnelli force-pushed on Jul 2, 2015
jonasschnelli force-pushed on Jul 2, 2015
jonasschnelli force-pushed on Jul 2, 2015
jonasschnelli force-pushed on Jul 2, 2015
jonasschnelli commented at 6:28 PM on July 2, 2015: contributor

Rebased and make use of the UniValue blockheaderToJSON(const CBlockIndex* blockindex) from #6247.
jonasschnelli force-pushed on Jul 5, 2015
[REST] add JSON support for /rest/headers/ c45c7ea0fa
jonasschnelli force-pushed on Jul 5, 2015
laanwj commented at 1:25 PM on July 10, 2015: member

ACK
laanwj merged this on Jul 10, 2015
laanwj closed this on Jul 10, 2015
laanwj referenced this in commit 943b322d5d on Jul 10, 2015
zkbot referenced this in commit 9af55822fb on Feb 15, 2017
zkbot referenced this in commit a7cf698873 on Mar 4, 2017
MarcoFalke locked this on Sep 8, 2021

Contributors