Add missing REST endpoints for SignMessage and VerifyMessage #2148
Conversation
| rpc VerifyMessage (VerifyMessageRequest) returns (VerifyMessageResponse); | ||
| rpc VerifyMessage (VerifyMessageRequest) returns (VerifyMessageResponse) { | ||
| option (google.api.http) = { | ||
| post: "/v1/verifymessage" |
There was a problem hiding this comment.
Perhaps this should be a GET instead as it doesn't mutate any state, doesn't produce anything new, and is also a stateless operation?
There was a problem hiding this comment.
Both SignMessage and VerifyMessage could in theory be implemented as GET. Problem is, as GET requests are not supposed to have a body this implies the message needs to go in the URL. Which produces potentially very long URLs and in certain scenarios the user could find limits on the size of the message that can be passed to these functions. What do you think?
There was a problem hiding this comment.
Thinking more about it, URL size limits are defined in clients not servers, and afaik only old browsers are problematic in that sense. So I guess this is not a real issue? I'd prefer to use the correct http verb here but I am just not 100% sure it's not an issue to pass messages in URLs.
There was a problem hiding this comment.
@Roasbeef I can make it a GET but I have a question. The field msg is of type bytes. Should I change it to string instead as it needs to be passed through a URL? Looks like that would break other stuff.
There was a problem hiding this comment.
bytes fields are encoded as base64 strings, but they're not URL safe, so perhaps it's better to keep it as a POST? Either that or we can note that the base64 string should be padded so that it's URL safe (https://stackoverflow.com/questions/1374753/passing-base64-encoded-strings-in-url), but this isn't very user friendly IMO.
Roasbeef
added
enhancement
|
Needs a rebase! |
|
@wpaulino rebased |
Fixes #2096