ElementsProject
clnrest: configurable content-type header
Make the content-type of REST responses configurable via config options, so that applications can consume the response without writing wrappers/interceptors; if they do not consume default application/json type.
I am working on adding properties http_path and http_method to a plugin command's manifest entry, this will allow plugins to set specific REST mappings for their RPCs rather than being fixed at /v1/<command_name>. Seems like a good place to include the content-type of the response, then this data can be handled by CLNRest to create dynamic routes
Open CLN bounty on this: https://community.corelightning.org/c/cln-bounties/7164-clnrest-configurable-content-type-header
I won't be working on this, I don't have the time and C is a big challenge for me
@ShahanaFarooqui is this still useful?
Currently, clnrest only responds in JSON format. Adding support for alternative response formats could be a useful enhancement for greater flexibility. While this is not urgent, it would be a valuable addition for future versions.
@daywalker90 – Let me know if you are interested in taking on this bounty. Otherwise, I will prioritise it when I have bandwidth.
@daywalker90 – Let me know if you are interested in taking on this bounty. Otherwise, I will prioritise it when I have bandwidth.
Is https://github.com/ElementsProject/lightning/pull/7529 what this issue is about? If so, yes, i'm trying but could need some help!
@daywalker90 This is completely unrelated to #7507, #7508, #7509, or #7529.
Current Behavior:
- GET /v1/list-methods: Returns HTML (content_type = "text/html")
- POST /v1/{rpc_method}: Returns JSON (content_type = "application/json")
Desired Behavior:
- Allow clients to request API responses in different formats (JSON, XML, Form-encoded, HTML, YAML, etc.) by sending request with
AcceptHeader. - If no Accept header is provided, default to
application/json. - Allow clients to send API payload in different formats with
Content-TypeHeader and convert it into json before forwarding it to the node. - If no Content-Type header is provided, default to
application/json. - If an unsupported format is sent/requested, return
406 Not Acceptable. - Convert the successful JSON received from CLN node into the requested format before sending the response to the client.
Like this #8383 ?
Yes, something like it.
While the original issue was only intended to consider the Content-Type header, I now see the value in supporting the Accept header as well for proper content negotiation. I have updated the issue description and Desired Behavior section to clarify this further. Apologies for any earlier confusion.