(#796) User should be responsible for request encoding with client endpoint#916
Conversation
|
Thanks, I'll work on the build failures. |
|
Can you rebase on master? |
|
Sure I can rebase, will do soon! |
4d9fbd4 to
9fd881c
Compare
|
Rebased. |
|
@peterbourgon, have you had a chance to take a look yet ? |
|
Sorry for the delay. We can't break the transport/http API by removing the Client type. Can you not incorporate the changes into that type? |
|
More concretely, I would want to see EncodeClientRequestFunc (probably better named CreateRequestFunc) as a field in the Client type, with a default implementation that has the current behavior (http.NewRequest) and an Option to set it to something else. |
I think this PR does not break it, only deprecates it (at least this is how I intended it to be). And if
We can go this route, but I see the following major obstacle, we initialize func NewClient(
method string,
tgt *url.URL,
enc EncodeRequestFunc,
dec DecodeResponseFunc,
options ...ClientOption,
) *Client {
...that is, we require the API consumer to pass in So, as API consumer if I want to create my requests through |
|
Hey, guys, can we follow-up on this ? (it's been some time ...) |
|
Hi, is there any progress here? I'd be cool to get this merged. |
|
I'm sorry for my lack of action on this PR, I simply haven't had the mental bandwidth to devote to this actually somewhat substantial change. I will make time before the end of the week to get it into shape and merged. @LasTshaMAN — in the interest of expediency, would it be OK with you if I made a PR to your PR to simply implement whatever changes I felt were appropriate? |
TODO:
Content-Length)