Skip to content

Unable to do anything with response Any protos in REST client #177

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
melissachang opened this issue Oct 31, 2016 · 5 comments
Closed

Unable to do anything with response Any protos in REST client #177

melissachang opened this issue Oct 31, 2016 · 5 comments
Assignees
Labels
🚨 This issue needs some love. triage me I really want to be triaged.

Comments

@melissachang
Copy link

In Go REST Apiary libraries, response Any proto is map[string]interface{}. I can't figure out how to convert this to any other type:

  • byte[]
  • Any proto
  • Original proto that Any proto represents

Ross requested me to mention some people: @bradfitz @jba @zombiezen

@zombiezen
Copy link
Contributor

The concrete proposal I had was that instead of having these fields generate an interface{} type, they should store a json.RawMessage. Then the user of the client could pick which message it should be and it becomes regular JSON semantics.

This would be a breaking API change, but I would argue that map[string]interface{} is unhelpful enough that it's worth it. FWIW, the current generator renamed the actual OperationMetadata struct to OperationMetadata1 to avoid conflicts with the type OperationMetadata interface{}.

@zombiezen
Copy link
Contributor

zombiezen commented Dec 9, 2016

So in testing this out in the real world, my fix has a correctness issue due to golang/go#14493: json.RawMessage fields get encoded as base64. While the correct behavior will land in Go 1.8, we have too many targets (namely App Engine) that aren't updated to 1.8. As I see it, there are two options:

  1. Roll back b679263.
  2. Roll forward and use *json.RawMessage.

@jba, thoughts?

@zombiezen zombiezen reopened this Dec 9, 2016
@zombiezen
Copy link
Contributor

@jba suggested an even better solution: creating a googleapi.RawMessage type that has the correct behavior, independent of Go version.

@dsnet
Copy link

dsnet commented Dec 9, 2016

Copying the implementation of json.RawMessage sounds like a good way to get around this problem. I think using *json.RawMessage is really dirty.

It would be nice to be able to alias googleapi.RawMessage as json.RawMessage in the not-so-distant future.

@zombiezen
Copy link
Contributor

Yup, https://code-review.googlesource.com/9811 out for review does exactly this.

@yoshi-automation yoshi-automation added triage me I really want to be triaged. 🚨 This issue needs some love. labels Apr 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🚨 This issue needs some love. triage me I really want to be triaged.
Projects
None yet
Development

No branches or pull requests

5 participants