How to get a standard http.Request form goreq.Request about goreq

[marcosnils]

@rexposadasi it's not a bad idea. Can you provide a snippet about how you'd use goreq and third party libraries so I can get an idea how to implement the API?

[rexposadas]

I'm writing a library which accepts an http.Request, make the call, and does some metrics on it. See this function signature. That function accepts a standard http.Request because, while using something like goreq is great, i don't want to force users to do that in order to use my library. I can see cases where some library creators feels the same way. So I was thinking of something like this.

req := goreq.Request{
Method: "POST"
Uri: "http://localhost:8000/myendpoint"
Body: body,
}

// req.Standard is simply a reference to a standard http.Request
simulate.MakeRequest(req.Standard)

[marcosnils]

@rexposadas I see where you're going and I have some questions though which may help to clarify the use case.

If your library does all the request handling how do you plan to return the request handler to goreq for all the remaining processing (ie: response, headers, redirects, etc)??.

To give an example:

req := goreq.Request{
Method: "POST"
Uri: "http://localhost:8000/myendpoint"
Body: body,
}

// req.Standard is simply a reference to a standard http.Request
simulate.MakeRequest(req.Standard)

//If we do this, then the request will be triggered two times against the targer URL. Once by your library and then by goreq
res, err := req.Do();

I believe a pluggable/middleware solution is more efficient in this cases where you need to sit between the request and the response to do some processing rather than just delegating the request handling to the library. We've thought to add middleware support to goreq so we can encourage some other projects (like yours) to sit between requests (currently Go default http client doesn't provide this functionality) but we haven't found the necessity or the time to do it so far.

I'm not saying we couldn't or shouldn't do it, I'm just trying to find the best use case for our users whenever they need to use both libraries.

[rexposadas]

I see what you mean. I guess my usecase is not common. What I'm trying to do is measure the time when a request gets called and when it returns. I didn't want to delegate that work in the middleware since I'm trying to get a very accurate reading. In this piece of code I am trying to guarantee that nothing happens between the time I start my timer, run a request, receive a response, then stop my timer. Using middleware to do that removes that guarantee.

But for all other things, I do agree that using a middle solution is the way to go.

Feel free to close this issue if you see fit. I do not think a change on your side would be beneficial to your target audience. And I can find a workaround.

[rexposadas]

Here is another situation of what I was thinking about..

http://golang.org/pkg/net/http/httputil/#DumpResponse

That standard package method accepts an http.Reponse, but I'm having difficulty using that library with goreq since goreq.Response cannot be passed to that method.

There are, at least, a couple of ways to tackle this situation:

1. add a method in goreq.Response which returns an http.Response
2. have a similar method to DumpResponse added to the goreq.Response object

[marcosnils]

@rexposadas you're correct. plz check out #85 and let me know your opinion so we can merge.
@xetorthio plz review as well.

[rexposadas]

@marcosnils thanks for that. I looked at #85. I think it's a step in the right direction. I would do something similar for goreq.Request.

i.e. having the ability to make use of http://golang.org/pkg/net/http/httputil/#DumpRequest

[marcosnils]

@rexposadas I've updated #85 with the ability to obtain the *http.Request with Goreq. Can you please check the PR and see if it sounds good from the user perspective?

Thanks!.

[rexposadas]

@marcosnils looks good to me. I can get a handle on the http.Request and http.Response, which was what I was after. Thanks for doing this.

[marcosnils]

closed by #85