不久前我发布了nosurf，这是Go语言的一个CSRF跨站请求伪造(Cross-Site Request Forgery)中间件。编写一个看起来简单并且小巧的包就足以让你爱上Go处理HTTP的方式。然而，这却取决于我们拥抱标准的HTTP设施或者是粉碎它，牺牲可组性和模块化。

与此同时，在Go语言中，唯一需要的接口自2009年就一直在发展中，尽管它从那时起经历了许多严重的改变，但是在2011年末，Go 1.0发布前的几个月，它已经变得非常稳定。

当然，我说的是mightyhttp.Handler。

type Handler interface {
ServeHTTP(ResponseWriter, *Request)
}

为了能够处理HTTP请求，你的类型仅仅需要实现这个方法就可以了。这个方法从给定的*Request读取请求信息，并且将响应信息写在给定的ResponseWriter中。看起来很简单，是吧？

然而，在此基础之上的建立抽象时，有些东西弄错了。举个例子，Mango，被它的作者描述为“一个模块化的Go语言Web应用程序框架，灵感来自Rack和PEP333”。
这是一个Mango应用程序的样子：

func Hello(env mango.Env) (mango.Status, mango.Headers, mango.Body) {
return 200, mango.Headers{}, mango.Body("Hello World!")
}

看起来简单，简洁，并且非常类似于WSGI或者Rack，对不对？除了一件事情。在使用动态/鸭式类型时，你可以在任何一个body上用上迭代，这里的mango.Body只是一个简单的字符串。从本质上讲，这样就丢掉了做任何形式的流式响应的能力。即便是暴露一个ResponseWriter，任何写入它的东西都将与返回的值冲突，因为它们只在函数结束时返回，在已经调用了ResponseWriter之后。

这不好。你是否需要基于现有的net/http的另外一个接口，只是你的口味问题，但即使你这样做了，它也不应该拿掉其它的功能。一个接口，在其上的编写代码感觉更棒，但是它带走了重要的功能，显然就逊色了。

现在流行的一个“微型”Web框架web.go使用了一种简单，但更好的方法。它的处理程序使用一个指向web.Contextas的指针作为可选的第一个参数。

type Context struct {
Request *http.Request
Params map[string]string
Server *Server
http.ResponseWriter
}
// ...
func hello(ctx *web.Context, val string) string {
return "hello " + val
}

web.Context不再采取标准的HTTP处理程序结构。相反，Request参数可作为结构成员和Context，实现ResponseWriter所需要的方法，故而就让它自身就嵌入了原来的ResponseWriter。你从函数返回字符串（如果有的话）只是简单的追加到了response上。

这是一个很好的设计选择，我认为它能迎合Go的理念。尽管你得到一个不错的更高级别的API，但你不必牺牲对请求处理的底层控制。

Go的HTTP库基础设施，尽管增长迅速，却仍然有一些空白需要填补。但是我们需要注意的最后一件事是碎片与恼人的不兼容性，这是由于糟糕的设计和实际上带走许多功能的抽象所导致。依我之见，拥抱和支持标准的Go HTTP设施就是，最直接地拥有功能化和模块化的第三方HTTP工具。

相关阅读：