时时彩三分彩开奖结果:Gin middleware中间件使用实例

  • A+
所属分类:golang

I've been playing around with Gin web framework in Go for a while for small side projects and its been amazing so far. Gin attracted me by its simplicity and compatibility with a default net/http library and somewhat similarity with Sinatra, which is a minimalistic web framework for Ruby. So far i've written a few open source projects powered by Gin:

While most of those projects are pretty simple under the hood, i started to explore more on how to bring some of my experience with Sinatra into Go. In particular i was interested how to write middleware handlers. You can check Gin's documentation, there's a few small samples.

Here's the baseline app:

 

Now, lets add some middleware:

In example above there's a call c.Next(). It means that after our middleware is done executing we can pass on request handler to the next func in the chain. As you can see, middleware functions are no different from regular endpoint functions as they only take one argument *gin.Context. However, there's also another way of defining middleware functions, like this one:

The difference between those two ways of defining middleware functions is that you can do some initialization logic in later example. Say you need to fetch some data from a third-party service, but you cannot do that on per-request basis. When middleware gets loaded into request chain, whatever you define before the return statement (Foo() in example) will be executed only once. This could be useful if you want to have condition checking, like return one middleware function if one header is present, or another one if its not. Lets move onto examples!

Api authentication middleware

If you're building an API with Gin, you will probably want to add some sort of authentication mechanism into your application. Easiest solution is to check if client has provided an additional url parameter, like api_token. Then it should be validated on each request before anything else.

Example above will check for presence of api_token parameter on every request and validate it against one defined as API_TOKEN environment variable. The important part is if you need to terminate request chain, you can call c.Abort. This will prevent any other handlers from execution.

Code revision middleware

This type of middleware usually injects special headers into request response that could provide some idea on which git commit your application is running. In Ruby world that git sha is usually stored in REVISION or COMMIT file in the release directory, created by capistrano or other deployment tools. In fact, i created rack middleware just for that.

As a result you'll get a new header in http response:

Request ID middleware

Ofter API services inject a special header X-Request-Id to response headers that could be used to track incoming requests for monitoring/debugging purposes. Value of request id header is usually formatted as UUID V4.


After you make a request to your service, you'll see a new header in the response, similar to this one:
weinxin
微信公众号
扫一扫关注运维生存时间公众号,获取最新技术文章~

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: