Go 的 HTTP 工具

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

http.Handler是接口

使用特定编程语言编写的web应用程序中的统一HTTP接口,如Python中的WSGIRuby中的Rack都是一种很好的想法,但是它们却不总是在一起,例如,Rack2007年出现的时候,Rails就已经很健壮并且风靡了好一阵子。

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

当然,我说的是mightyhttp.Handler

 

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

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

补充它,但不能取代它

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

这是一个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,但你不必牺牲对请求处理的底层控制。

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

转自:http://www.oschina.net/translate/embrace-gos-http-tools

 原文:http://justinas.org/embrace-gos-http-tools/

本文来自:CSDN博客

感谢作者:rznice

查看原文:Go 的 HTTP 工具

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。