Use hex encoding for raw bytes in REST API #286
Conversation
By using our fork of google.golang.org/protobuf that encodes raw bytes as hex for the REST proxy, this automatically turns all raw byte gRPC fields into hex encoded strings in the REST API.
| // should be used when interacting with the REST proxy only. | ||
| RESTJsonUnmarshalOpts = &protojson.UnmarshalOptions{ | ||
| AllowPartial: false, | ||
| UseHexForBytes: true, |
There was a problem hiding this comment.
q: I guess it's to late to change this in LND too because other tools are using already base64 encoding?
There was a problem hiding this comment.
I thought about adding an option to give the user the choice. But the problem is that yes, most of the apps using the REST interface now rely on the raw bytes being base64 encoded. So it shouldn't be the user's choice but rather the developer's. This gives me an idea though: Maybe there is a way to specify the desired encoding as a HTTP header field? For example: Accept: application/json+hex instead of just Accept: application/json...
|
|
||
| // We want to format raw bytes as hex instead of base64. The forked version | ||
| // allows us to specify that as an option. | ||
| replace google.golang.org/protobuf => github.com/lightninglabs/protobuf-go-hex-display v1.30.0-hex-display |
There was a problem hiding this comment.
Why not just import it directly?
There was a problem hiding this comment.
Because we need to keep it as the original package name, if I import it directly I get this error:
module declares its path as: google.golang.org/protobuf
but was required as: github.com/lightninglabs/protobuf-go-hex-display
And renaming the package in the fork would require a way bigger diff than just protocolbuffers/protobuf-go@9c1f7c5 as we'd need to refactor a bunch of usages of the internal package as well. So rebasing the hex render feature on top of a new version in the future would become a bigger task, potentially causing us to lag behind on the versions of this package.
This is a follow-up to #286 which allowed developers to specify any raw bytes as a hex string in the REST API (instead of the library default of base64). The only area where that change didn't apply is the URI part of REST calls. For those we need to use a string field to support hex encoding, the same way we already did for the universe REST API.
This is a follow-up to #286 which allowed developers to specify any raw bytes as a hex string in the REST API (instead of the library default of base64). The only area where that change didn't apply is the URI part of REST calls. For those we need to use a string field to support hex encoding, the same way we already did for the universe REST API.
Fixes #282.