HTTP tools to embrace Go

This is a creation in Article, where the information may have evolved or changed.

I released Nosurf a while ago, It is a go middleware that mitigates cross-site request forgery attacks. Writing a package that looks simple and small is enough to make you fall in love with how go works with HTTP. It is up to us to embrace the standard HTTP facility or use fragmentate, sacrificing composition and modularity. http. Handler is the interface

At the same time, on go, the only interface needed has been in development since 2009, and although some significant changes have been made, it has stabilized by the end of 2011, when Go1.0 was released a few months ago. Of course, here I'm talking about powerful http. Handler.

Type Handler Interface {    servehttp (Responsewriter, *request)}

in order to be able to handle HTTP requests, your type only needs to implement this method. The method reads the request information from the given request and writes a response to the given responsewriter. It seems like a simple thing, right?

Replenish it, but not replace it

However, some things are mistaken when building abstractions based on this. For example, Mango, described by its author as "A Modular Go Language Web application framework, is inspired by rack and PEP333".
This is what a mango application looks like:

Func Hello (env Mango. ENV) (Mango. Status, Mango. Headers, Mango. Body) {  return, Mango. headers{}, Mango. Body ("Hello world!")}

This is not good. Whether you need another interface based on the existing net/http is just your taste problem, but even if you do, it should not take away other functions. An interface that writes code on it feels better, but it takes away important features, and it's obviously less.

The right way Now a popular "mini" web framework Web.go uses a simple but better approach. Its handlers use a point to the web. The Contextas pointer is the first parameter that is optional.

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. The context no longer takes the standard HTTP handler structure. Instead, the request parameter can be used as a struct member and context to implement the method required by Responsewriter, so that it embeds itself in the original responsewriter. The string you return from the function (if any) is simply appended to the response. This is a great design choice, and I think it caters to the idea of go. Although you get a nice, higher-level API, you don't have to sacrifice the underlying control of request processing.

Let's get started. Go's HTTP Library infrastructure, despite its rapid growth, leaves a gap that needs to be filled. The last thing we need, however, is the loss of functionality and fragmentation caused by design and abstract problems, which can lead to annoying compatibility issues. Embracing and supporting standard go language HTTP facilities, according to my humble opinion, the most straightforward way is to use functional and modular third-party HTTP tools.