Support Accept HTTP header in REST API #32583

1. 
   romanz commented at 5:15 am on May 22, 2025: contributor

   Please describe the feature you’d like to see added.

   Following #32540 (comment), I would like to add support for the HTTP Accept header, in addition to current “suffix-based” data format detection: https://github.com/bitcoin/bitcoin/blob/87ec923d3a7af7b30613174b41c6fb11671df466/src/rest.cpp#L137-L160

   WDYT?

   Describe the solution you’d like

   I would suggest checking the HTTP request Accept header, and using it to if there is no suffix set:

   I wonder about just adding a content-type like option so that the api endpoint is the same but you simply say if you want binary or json content returned?

2. romanz added the label Feature on May 22, 2025
3. 
   maflcko commented at 12:37 pm on May 22, 2025: member

   Not sure. This means there will be two conflicting? ways to specify the same. I don’t see the benefit either.
4. 
   romanz commented at 1:39 pm on May 22, 2025: contributor

   Thanks @maflcko - you’re right, it’s better to have one way for specifying the expected content format. @yancyribbens WDYT?
5. 
   yancyribbens commented at 1:07 pm on May 24, 2025: contributor

   I’m not sure what is meant by two conflicting types really.

   I was thinking it would be possible to make a request using either json or binary in the request HTTP header. For example:

   0curl -X POST https://bitcoin
   1   -H 'Accept: application/json'
   

   OR

   0curl -X POST https://bitcoin
   1   -H 'Accept: application/octet-stream'
   

   If no Accept content type is set then default to what it is now, json.

   I’m not sure, is that what the code snippet above is doing? I don’t really grok what’s happening with format string.

6. 
   sipa commented at 1:18 pm on May 24, 2025: member

   I don’t understand the point of this. The format is already specified using the extension, which seems more convenient to me than needing an additional header to specify the content type, and having two distinct ways of specifying it seems significantly worse than just having one.

   I’m not sure what is meant by two conflicting types really.

   I suspect Marco means: what do you do if someone requests /block/$BLOCKHASH.bin, but with Accept: application/json header.

7. 
   yancyribbens commented at 1:37 pm on May 24, 2025: contributor

   The format is already specified using the extension, which seems more convenient to me than needing an additional header to specify the content type,

   Oh, if one can say .bin or .json in the request to specify the expected content format that’s great.

   In the PR #32540

   We can significantly optimize it by adding a new REST endpoint, using a binary response format (returning a collection of spent txout lists, one per each block transaction)

   So I was suggesting instead of adding a new endpoint, to add a way to specify content type instead, either via http header or via format if that works. Maybe I missed the point of PR 32540 in that the new endpoint is doing more than just changing the response format.

8. 
   sipa commented at 1:40 pm on May 24, 2025: member

   I suggest you read the documentation on the REST interface before commenting on it.

   #32540 adds a new REST endpoint, which provides information that no current endpoint provides. Like all REST endpoints, it provides this information in a number of formats, based on the extension of the filename used in the request.

9. 
   yancyribbens commented at 1:42 pm on May 24, 2025: contributor

   I suggest you read the documentation on the REST interface before commenting on it.

   #32540 adds a new REST endpoint, which provides information that no current endpoint provides. Like all REST endpoints, it provides this information in a number of formats, based on the extension of the filename used in the request.

   I see that now. My mistake.

10. 
    yancyribbens commented at 1:50 pm on May 24, 2025: contributor

    @romanz sorry to lead you astray, I should have inspected your PR a bit closer.
11. 
    romanz commented at 3:31 pm on May 24, 2025: contributor

    No problem :)
12. romanz closed this on May 24, 2025

    ---

Contributors
romanz maflcko yancyribbens sipa

Labels
Feature