mapping HTTP headers to RPC request / responses

[toumorokoshi]

🚀 Feature

Hello! I'm interested in a way to specify how to map http headers to fields a in gRPC request / response. I see this is noted in the readme as "patches welcome":

Method parameters in HTTP headers.

I'm happy to do some work in this area, but I'd like to sanity check my approach first.

Specifically, I'm hoping there can be some generic way of specifying these, similar to the existing google.api.http headers. I have a proposal I've added here: googleapis/googleapis#1005

Ideally we could go with the Google route, but I am also working on an evolution of the AIPs known as "aep.dev" (https://aep.dev/blog/history-of-aeps/), in which we are proposing our own proto extensions. If there's interest, we could add a similar generic mechanism to describe the extension (example of our fork of long-running operations here: https://github.com/aep-dev/aep-components/blob/main/proto/aep-api/aep/api/operation.proto#L37).

Thoughts on either of those approaches? or would a different approach be preferred?

[johanbrandhorst]

Hi, thanks for your issue! If the proposal is accepted and the spec is updated, I'd certainly be interested in having it implemented. I'm not sure I'd want us to implement anything non-standard though. I think it's possible to do what you suggest today already with a metadata middleware option, though, of course, it won't be well typed or generic.

[toumorokoshi]

Thank you! By "standard", are you defining that as being a part of google.api.http? or would you accept an extension from a different group like AEPs?

I think the challenge is to get Google to update the googleapis proto. For aeps, We have previously discussed just using metadata, but the discussion offline was that it didn't feel like a native interface relative to header/field mapping similar to query parameters: aep-dev/aeps#289

[johanbrandhorst]

Sorry to be unclear. Yes, I think the definitions in google.api.http define the standard we work to support. I don't think a third party standard would be appropriate for us to support at this time, unless it's clear that the old standard is abandoned. I appreciate that it is very hard to get the big bear to move or care, but I don't think we're interested in implementing anything non standard here, so you'll have to go back to them first I'm afraid. Of course, you're always welcome to fork and experiment with new functionality in compliance with our license.

[toumorokoshi]

Thanks for the clarification! For the record I am trying to work with googleapis first, although finding the right owner to start the conversation has been difficult: googleapis/googleapis#1005