Expose request to handlers

[phonkee]

Request should be exposed for all handlers. What if you want to read headers (authentication, ip address, etc...)

[macu]

This is a good idea. It wouldn't hurt to pass the full *http.Request to the handler, which provides access to cookies, the sent headers, the user agent string, and more, but reading headers tends to go along with writing headers.

This opens the question "How far should it go?" Suppose the handler would be able to write headers as well, then the Header map from the ResponseWriter would have to be passed along to handlers as a separate parameter. It wouldn't be appropriate to pass the ResponseWriter because sleepy deals with that.

type GetSupported interface {
    Get(*http.Request, http.Header) (int, interface{})
}

That doesn't seem like too much complexity, but some users might not care about the request and header at all, but would still have to import the "net/http" package for the parameter types. That could replace the "net/url" they already import.

As a further possibility, sleepy could define two interfaces per GET, PUT, etc.—one with a handler method that accepts no parameters, and one that accepts both the request and header map. But that's as far as I'd go; any further and it opens the door for too many permutations of parameters and return types. There are go libraries that do dependency injection. sleepy provides a super minimal utility and that's it's appeal.

There are other plans too (#8, #9) so I bet the handler signature will look quite different a month from now.

[dougblack]

Hey guys, sorry for the very delayed response.

My vision for sleepy is that it is simple and easy to get going. Part of fulfilling that vision is that sleepy will parse the request and give it to the handlers in a simple-to-use format. Passing the entire request to the handlers is pretty contrary to that idea.

I agree that the request object needs to be exposed somehow, but I don't want it to be directly passed in to the handlers.

Thanks for the ideas!