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

Support more message kinds as parameter types #152

Closed
torkelrogstad opened this issue Jan 5, 2025 · 4 comments
Closed

Support more message kinds as parameter types #152

torkelrogstad opened this issue Jan 5, 2025 · 4 comments

Comments

@torkelrogstad
Copy link
Contributor

Based on my reading of isWKTWithScalarJSONMapping and its usage, it seems like the only messages that's supported for parameters are primitive wrappers and google.protobuf universe. Would be great to also support more types from the google.type universe. I'm interested in using google.type.Date, at least.

@emcfarlane
Copy link
Collaborator

Hey @torkelrogstad you are correct, currently there is no custom formatting for JSON types (see this related issue that asks for google.type.Date). The parameter mapping uses the proto JSON representation and is restricted to these subset of types. Adding custom formats would have to be done with a custom JSONCodec. It would need to alter the methods MarshalAppendField and UnmarshalField to handle the date type marshalling. Hope that helps!

@rauanmayemir
Copy link

I too am interested in this.

@emcfarlane Followed your advise and started looking into JSONCodec. However, the MarshalAppendField function is just for pulling response_body fields, encoding still happens in MarshalAppend which is just a proxy for protojson.MarshalOptions.MarshalAppend.

@emcfarlane
Copy link
Collaborator

@rauanmayemir correct, to do custom JSON encoding that isn't parameter methods you would need to alter the MarshalAppend methods as well. This would have to be respected by both the client and the server so would not be a compatible with other implementations across the different language runtimes. However if all your clients are controlled by you then using the custom JSON methods would be an option.

@rauanmayemir
Copy link

Yeah, it's a bit too invasive just to have google.type.Date as string, so I tabled the idea for now.

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

4 participants