#sendRequest ought to accept request header

[k-wall]

Is your feature request related to a problem? Please describe.

As a filter author using the sendRequest API, I may need to specify a header. A likely user case is that I need to set clientId on the request, which currently I am unable to do. The implementation current manufactures an clientId.

There's also a separate argument for API consistency - the rest of the API already expects the header, body tuple.

Describe the solution you'd like

#sendRequest(@Nullable RequestHeaderData, @NonNull ApiMessage)

• ApiMessage will be validated as being a class with the name RequestData otherwise throw IllegalArgumentException
• If RequestHeaderData is null, the implementation will manufacture one. For apiVersion it should default to the highest supported version that was agreed during ApiVersion negotiation.
• If RequestHeaderData is not null
  • the apiVersion should be clamped by the range agreed by ApiVersion negotiation, but otherwise the value respected. This gives the user a mechanism to influence the version. This idiom would emerge that indicates to Kroxylicious to use the highest version it can.

       sendRequest(new RequestHeaderData().setRequestApiVersion(ProduceRequestData.HIGHEST_SUPPORTED_VERSION), new ProduceRequestData())
  

  • the RequestHeaderData#apiKey will be overwritten by message.apiKey(). RequestHeaderData#apiKey defaults to 0 which is actually means PRODUCE.
  • other header fields, clientId, additionalTags would be respected.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[robobario]

We discussed in our call whether this should go into 0.3.0 along with all the other breaking changes. We decided it doesn't have to be in 0.3.0 and that we should start firming up our API stability, so this might be implemented as a second sendRequest method and we can start going through (quite rapid) deprecate+delete of the old method.

[robobario]

We should also make the response headers available, so instead of CompletionStage<ApiMessage> it should probably be CompletionStage<Response> where response wraps up header/body.

[k-wall]

We should also make the response headers available, so instead of CompletionStage<ApiMessage> it should probably be CompletionStage<Response> where response wraps up header/body.

Agreed, or alternatively CompletionStage<ResponseHeader, ApiMessage>