Introduction

For this blog post we are going to take a look at the http.HandlerFunc type and how we can improve it to make more elegant and clean handlers. Following the idioms of Go and staying compatible with the standard library.

Handlers

In Go A Handler is a type which responds to an HTTP request.

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

Any structure implementing the ServeHTTP method from the interface can be used to handle http requests. This is very powerful and flexible. It is easy to add http handling capabilities to any structure in your program.

Altough most of the time this is not the way a lot of people do it. It is still limited to the fact that you need to implement it on a structure which is not always what you would like. A single function would be easier to use than implementing an interface. Luckily Go has an solution for this.

Say Hi to the http.HandlerFunc

type HandlerFunc func(http.ResponseWriter, *http.Request)

The HandlerFunc is basically an adapter for the Handler interface. Because the HandlerFunc is a type it can implement methods on that type. Note that the type is actually a function so any function containing the same signature as the HandlerFunc can be easily casted to this type. When passing it as a parameter this happens implicitly and you wont even know the difference.

Ok cool, so here we are we’ve seen how the Handler and HandlerFunc works, but how can we actually extend them? And why do we even need to extend them, they are already powerfull aren’t they?

If you have ever written more complex http request handlers in Go you probably know that they can grow really big because of the verbose error handling and early returns.

func IndexHandler(w http.ResponseWriter, r *http.Request) {
// Do something
v, err := ...
// check for err
if err != nil {
w.WriteHeader(http.StatusInternalServerError)
w.Write([]byte(err.Error()))
return
}
// More code
// ...
}

This is common code and because the functions returns void we have to terminate the function early if we wan’t to stop the function from writing more to the given io.Writer. Ofcourse an else would be possible here aswell but that would just decrease the readability, because statements will be more and more nested and harder to follow.

But most of the functions in Go returns errors when something failed instead of notifying through an given pointer in the parameters (after all we aren’t programming in C right)?

So how can we change this and still make use of the great integration with the standard library and the http.Handler interface. For this we are going to take the idea of http.HandlerFunc and create our own adapter for the Handler interface which can work with return types.

But first we need to find the perfect return types for our functions. Only an error would not be sufficient because we still have to set the status code on the ResponseWriter. We could make a generic struct which can contain most of the information we would like to send to the caller, this would look like this:

// Map of string to string where the key is the key for the header
// And the value is the value for the header
type Headers map[string]string // Generic response object for our handlers
type Response struct {
// StatusCode
Status int
// Content Type to writer
ContentType string
// Content to be written to the response writer
Content io.Reader
// Headers to be written to the response writer
Headers Headers
}

The same as how the HandlerFunc works we create a type alias for our function definition. The type will return the new created response object by us.

type Action func(r *http.Request) *Response

We omitted the response writer as paramater because we don’t need it in our functions. We won’t be writing to the response writer from inside our function (this breaks the paradigm we want to accomplish). The response struct is the way for us to write content to the response writer. Now we need to make our Action type compatible with thehttp.Handler interface by implementing the ServeHTTP method on it.

func (a Action) ServeHTTP(rw http.ResponseWriter, r *http.Request) {
if response := a(r); response != nil {
if response.ContentType != "" {
rw.Header().Set("Content-Type", response.ContentType)
}
for k, v := range response.Headers {
rw.Header().Set(k, v)
}
rw.WriteHeader(response.Status)
_, err := io.Copy(rw, response.Content) if err != nil {
rw.WriteHeader(http.StatusInternalServerError)
}
} else {
rw.WriteHeader(http.StatusOK)
}
}

A few things going on here. First we declare the method on the function and we call the type Action which is in essence just a plain function. So every function with the same type signature as the Action can be converted to this Action type. As we know our Action type gave back a pointer to a Response struct. For this to work correctly we need to check if the pointer is not nil. Otherwise the program would panic when calling the Status and Message property on them. By using a pointer it gives us also the extra benefit of that we can return nil in our functions and nothing will be done (the default value of 200 OK will be send to the caller). We still have the same flexibility of the regular http.HandlerFunc and we are in control of when something will be written to the response writer.

Ok cool, with this in place we have some nice functions to work with. We can now return in our handlers and everything will be fine. We can now write some wrapper functions so we don’t have to manually create our Response struct.

Because our response struct works with an io.Reader interface we cannot just simply return the error in there so we need to first create a wrapper for this. We use a io.Reader here because this way we stay flexible, we can return any reader (even a stream reader) in our handlers and it will be streamed to the response writer.

func Error(status int, err error, headers Headers) *Response {
return &Response{
Status: status,
Content: bytes.NewBufferString(err.Error()),
Headers: headers,
}
}

This function pretty much explains itself. We pass in an error and we let the function convert it to an io.Reader with using an internal buffer. We can use it like this:

func Index(r *http.Request) *Response {
return Error(404, errors.New("not found"), nil)
}

Sweet! that looks way more clear than before. Let’s take it a step further, nowadays a lot of people are making rest api’s which spit out JSON to the caller. We can easily create a function for this.

type errorResponse struct {
Error string `json:"error"`
} func ErrorJSON(status int, err error, headers Headers) *Response {
errResp := errorResponse{
Error: err.Error(),
} b, err := json.Marshal(errResp) if err != nil {
return Error(http.StatusInternalServerError, err, headers)
}
return &Response{
Status: status,
ContentType: "application/json",
Content: bytes.NewBuffer(b),
Headers: headers,
}
}

NOTE We can use the ErrorJSON functions again in our handlers. And it will do the conversion to JSON for us.

func Index(r *http.Request) *Response {
return ErrorJSON(http.StatusNotFound, errors.New("not found"), nil)
}

and it will print:

{
"error": "not found"
}

With those helper functions we can create responses for every content-type you would like; ErrorXML etc. We’ve seen error handling and how we can elegant create custom responses for our errors. How does this work for returning something else than en error?

We can create a generic functions (same as the error function) for regular data aswell.

func Data(status int, content []byte, headers Headers) *Response {
return &Response{
Status: status,
Content: bytes.NewBuffer(content),
Headers: headers,
}
}

Example usage:

func Index(r *http.Request) *Response {
return Data(http.StatusOK, []byte("test"), nil)
}

Same as the errors we could take this a step further and implement some helper functions who will do marshalling of data to JSON.

func DataJSON(status int, v interface{}, headers Headers) *Response {
b, err := json.Marshal(v) if err != nil {
return ErrorJSON(http.StatusInternalServerError, err, headers)
} return &Response{
Status: status,
ContentType: "application/json",
Content: bytes.NewBuffer(b),
Headers: headers,
}
}

Here we accept an interface in our method and let the json package take care of the conversion between the incoming v and the byte array. If we encounter some error during marshalling we just return our ErrorJSON function and the caller will be notified with the error (note this should probably be logged instead of returning the actual error to the caller). We do the same trick as in our ErrorJSON method and set the right content type. Usage is the same as all the other methods.

type temp struct {
Message string `json:"msg"`
} func Index(r *http.Request) *Response {
return DataJSON(http.StatusOK, temp{"test"}, nil)
}

We can also create our helper function for the standard io.Reader this way we can return any reader we would like. This could be a external http or anything implementing theio.Reader interface.

func DataWithReader(status int, r io.Reader, headers Headers) *Response {
return &Response{
Status: status,
Content: r,
Headers: headers,
}
}

With this in place we have all the flexibility we would like and can return anything we can even think off. We eliminated the verbose writing to the response writer and made our handlers look way cleaner and easier to follow. Without losing perfomance or flexibility.

Compatibility with the standard library

Because our handlers are still of type http.Handler we can use them anywhere where the http.Handler interface is used.
Lets try it out! We are going to create middleware for loggin the details about a request

func logger(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
log.Printf("[%s] User agent => %s Remote addr => %s", r.Method, r.UserAgent(), r.RemoteAddr)
next.ServeHTTP(w, r)
})
}

We can create a route in main

func main() {
http.Handle("/test", logger(Action(Index)))
http.ListenAndServe(":8080", nil)
}

And it all works. We can chain the middleware and use existing middlewares with our new handler types.

Conclusion

The http.Handler interfaces gives a lot of flexibility and by using type aliasing in Go we can easily convert our functions to actual methods which implement the Handler interface. It is even possible to extend our Response object with more options. This is all up to you and you can modify the wrappers to use the new options you define. (Extra headers for example).

the full code can be found here Github Gist. Let me know what you think about it and what could be improved.

Thanks for reading and happy coding! (y)

Clean http handlers in Go的更多相关文章

  1. 转: GUI应用程序架构的十年变迁:MVC,MVP,MVVM,Unidirectional,Clean

    十年前,Martin Fowler撰写了 GUI Architectures 一文,至今被奉为经典.本文所谈的所谓架构二字,核心即是对于对于富客户端的 代码组织/职责划分 .纵览这十年内的架构模式变迁 ...

  2. A little bit about Handlers in JAX-WS

    by Rama Pulavarthi Handlers are message interceptors that can be easily plugged in to the JAX-WS run ...

  3. 【C#】转一篇MSDN杂志文:ASP.NET Pipeline: Use Threads and Build Asynchronous Handlers in Your Server-Side Web Code

    序:这是一篇发表在2003年6月刊的MSDN Magazine的文章,现在已经不能在线阅读,只提供chm下载.讲的是异步请求处理那些事,正是我上一篇博文涉及的东西(BTW,事实上这篇杂志阐述了那么搞然 ...

  4. Android 程序架构: MVC、MVP、MVVM、Unidirectional、Clean...

    摘选自:GUI 应用程序架构的十年变迁:MVC.MVP.MVVM.Unidirectional.Cleanhttps://zhuanlan.zhihu.com/p/26799645 MV* in An ...

  5. GUI应用程序架构的十年变迁:MVC,MVP,MVVM,Unidirectional,Clean

    十年前,Martin Fowler撰写了 GUI Architectures 一文,至今被奉为经典.本文所谈的所谓架构二字,核心即是对于对于富客户端的 代码组织/职责划分 .纵览这十年内的架构模式变迁 ...

  6. Error:Execution failed for task ':app:clean'.

    运行时出现 Error:Execution failed for task ':app:clean'. 错误,Builld->Clean Project即可.

  7. 学习Maven之Maven Clean Plugin

    1.maven-clean-plugin是个什么鬼? maven-clean-plugin这个插件用maven的人都不陌生.我们在执行命令mvn clean时调用的就是这个插件. 这个插件的主要作用就 ...

  8. AndroidStudio中make Project、clean Project、Rebuild Project的区别

    1.Make Project:编译Project下所有Module,一般是自上次编译后Project下有更新的文件,不生成apk. 2.Make Selected Modules:编译指定的Modul ...

  9. Clean Old Kernels on CentOS

    1. Check Installed Kernels $ rpm -q kernel 2. Clean Old Kernels ## need Install yum-utils ## ## Pack ...

随机推荐

  1. DB2常用命令2

    1.启动实例(db2inst1):实例相当于informix中的服务 db2start 2.停止实例(db2inst1): db2stop 3.列出所有实例(db2inst1) db2ilist 4. ...

  2. Eclipse如何提高开发效率

    Ctrl+Shift+J 反向增量查找(和上条相同,只不过是从后往前查) Ctrl+Shift+F4 关闭所有打开的Editer Ctrl+Shift+X 把当前选中的文本全部变为小写 Ctrl+Sh ...

  3. Storm 提交多个流例程

    1.拓扑(Topology): builder.setBolt(TRANSFORM_BOLT, new TransformationBolt(), 1).shuffleGrouping(MY_SPOU ...

  4. Python基本数据类型之列表、元组、字典、集合及其魔法

    列表 1.列表可存放任何东西,并且可修改 2.列表有序 3.列表支持索引与切片 4.支持for,while循环,所以列表为可迭代对象 5支持in操作,判断元素是否在列表中 6可多重索引嵌套列表 7.字 ...

  5. 几大时尚前端UI框架的IE支持

    这个文章的Topic比较符合我们这些身在Stone Age用户环境中的开发者所考虑的因素 1.先说目前最火最酷的:Semantic-UI 目前版本:0.17.0 Browser Support Las ...

  6. JavaScript匿名自执行函数~function(){}

    原博客:https://blog.csdn.net/yaojxing/article/details/72784774 1.匿名函数的常见场景 js中的匿名函数是一种很常见的函数类型,比较常见的场景: ...

  7. python笔记:#014#综合应用

    综合应用 -- 名片管理系统 目标 综合应用已经学习过的知识点: 变量 流程控制 函数 模块 开发 名片管理系统 系统需求 程序启动,显示名片管理系统欢迎界面,并显示功能菜单 ************ ...

  8. Windows下Markdown软件的选择

    从开始Java学习这个系列的同时,我也开始改用Markdown而不是无比蛋疼的博客园默认编辑器来进行博客管理.但是Windows下想找一个比较好的Markdown编辑器蛮困难的,可以说专门的Markd ...

  9. Java (三、数组)

    Java 数组 数组对于每一门编程语言来说都是重要的数据结构之一,当然不同语言对数组的实现及处理也不尽相同. Java 语言中提供的数组是用来存储固定大小的同类型元素. 声明数组变量 首先必须声明数组 ...

  10. 从 源码 谈谈 redux compose

    compose,英文意思 组成,构成. 它的作用也是通过一系列的骚操作,实现任意的.多种的.不同的功能模块的组合,用来加强组件. 看看源码 https://github.com/reactjs/red ...