HTTP Tools for Go

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

Nosurf, this is a CSRF cross-site request forgery (Cross-site requests forgery) middleware for the Go language. Writing a seemingly simple and compact package is enough to make you fall in love with the way Go handles HTTP . However, it is up to us to embrace the standard HTTP facility or to smash it, sacrificing the scalability and modularity.

http. Handler is an interface

Unified HTTP interfaces in Web applications written in a specific programming language, such as WSGI in Python and Rack in Ruby is a good idea, but they are not always together, for example, when theRack appeared in the year,Rails was very strong and popular for a while.

At the same time, in the go language, the only interface required has been in development since the year, although it has experienced many serious changes from then on, but at the end of the day,Go 1.0 Months before the release, it has become very stable.

Of course, I'm talking about mightyhttp. Handler.

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

To be able to handle HTTP requests, your type simply needs to implement this method. This method reads the request information from the given *request and writes the response information in the given Responsewriter . It looks simple, doesn't it?

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!")}

It looks simple, concise, and very similar to WSGI or Rack, right? Except for one thing. When using the dynamic / duck type, you can use the iteration on any body , the mango here. The Body is just a simple string. Essentially, this loses the ability to do any kind of streaming response. Even if a responsewriteris exposed, anything written to it will conflict with the returned values because they are returned only at the end of the function, after the Responsewriter has been called.

It's 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, therequest parameter can be used as a struct member and Contextto implement the method required by Responsewriter , so that it embeds itself into the original Responsewriter . The string you return from the function (if any) is simply appended to the response .

This is a good design choice, I think it can cater to the concept of Go . Although you get a nice, higher-level API, you don't have to sacrifice the underlying control of request processing.

Go 's HTTP library infrastructure, despite its rapid growth, still has some gaps to fill. But the last thing we need to be aware of is fragmentation and annoying incompatibility, which is caused by the bad design and the abstraction that actually takes away many features. In my opinion, embracing and supporting the standard Go HTTP facility is the most straightforward to have a functional and modular third-party HTTP tool.

Transferred from: Http://www.oschina.net/translate/embrace-gos-http-tools

Original: http://justinas.org/embrace-gos-http-tools/