[REST] JSON support for /rest/headers

[jonasschnelli]

also includes REST documentation update for /rest/headers

[fanquake]

Needs rebase

[jonasschnelli]

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]

Code appears correct... I just wonder who would use JSON header queries.

[jonasschnelli]

@jgarzik couldn't we ask the same for json blocks? I just think we should have consistent output support over all rest calls.

[laanwj]

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]

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]

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]

utACK

[paveljanik]

ACK (I was about to add the missing /rest/headers documentation ;-)

[jonasschnelli]

Yes. This PR also includes the missing docs for already merged rest headers call (it's a separate commit).

[laanwj]

After #6247 this can use the existing BlockHeaderToJSON (see my comment about overlap there)

[jonasschnelli]

Rebased and make use of the UniValue blockheaderToJSON(const CBlockIndex* blockindex) from #6247.

[laanwj]

ACK