Skip to content
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

how to handle arbitrary (json) structs #395

Closed
lucas-natraj opened this issue May 17, 2017 · 9 comments
Closed

how to handle arbitrary (json) structs #395

lucas-natraj opened this issue May 17, 2017 · 9 comments

Comments

@lucas-natraj
Copy link

i haven't been able to find an example of how to support arbitrary json -> map[string]interface{}.
i've defined my message as:

message Entity {

    // The entity's key.
    string key = 1;

    // The entity's properties.
    google.protobuf.Struct data = 2;
}

as Struct seems to be the appropriate json equivalent in protobuf.

however, i am unable to invoke the corresponding REST endpoint using

{
    "key": "xyz",
    "data": {
        "name": "joe",
        "age": 28
    }
}

is there a way to support arbitrary json content and have it mapped to basically a map[string]interface{}?

not sure how I need to define my proto messages / services to support this.

@tamalsaha
Copy link
Collaborator

tamalsaha commented May 17, 2017

This is not a gateway question, rather what you can map into protocol buffer. The short answer is, you can't define arbitrary map[string]interface{} in protocol buffer. Please check here: https://developers.google.com/protocol-buffers/docs/proto3#oneof

To use protocol buffer, you need to know the schema of your data.

@lucas-natraj
Copy link
Author

lucas-natraj commented May 17, 2017

yeah, i understand that map[string]interface{} isn't really supported. i was just using it as an example of handling arbitrary content.

the struct message does, in fact, use oneof and I am able to receive it on the grpc service side.

however, when using the gateway, i have to send the json request body as

{
  "key": "xyz",
  "data": {
    "fields": {
      "name": {
        "stringValue": "joe"
      },
      "age": {
        "numberValue": 28
      }
    }
  }
}

which, while not ideal, does actual get parsed correctly by the gateway.
i was hoping there was a way to achieve the more natural json representation I mentioned earlier.

@tamalsaha
Copy link
Collaborator

I don't think you can do any better with oneof.

@tamalsaha
Copy link
Collaborator

As an alternative, you could use map[string]string, then deal with type conversion in your code. In that case, json form might look a bit nicer.

@lucas-natraj
Copy link
Author

hmm.. somewhat doable, although things quickly get mucky with nested objects.

oh well.. guess i'm outta luck.

thanks for your time @tamalsaha.

@bobbytables
Copy link

I'm pretty sure this can solve this for anyone else that finds this issue: https://godoc.org/github.com/golang/protobuf/jsonpb#Unmarshal

@derekperkins
Copy link

@bobbytables Not quite sure what you mean. How does that let you map arbitrary json to a field?

@derekperkins
Copy link

This worked for us: https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#struct

@vnt32
Copy link

vnt32 commented Sep 2, 2022

yeah, i understand that map[string]interface{} isn't really supported. i was just using it as an example of handling arbitrary content.

the struct message does, in fact, use oneof and I am able to receive it on the grpc service side.

however, when using the gateway, i have to send the json request body as

{
  "key": "xyz",
  "data": {
    "fields": {
      "name": {
        "stringValue": "joe"
      },
      "age": {
        "numberValue": 28
      }
    }
  }
}

which, while not ideal, does actual get parsed correctly by the gateway. i was hoping there was a way to achieve the more natural json representation I mentioned earlier.

Thanks, I barely found how to use this thing, because. not in one guide google this is not written. Used shnake_case instead of camelCase based on type from proto file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants