REST Servers in Go: Part 3 - using a web framework - Eli Bendersky's website

Gin: A Framework-First Take on the Same REST Server

This installment of our REST server series moves from the standard library and router packages to a full web framework. The framework in question is Gin, one of the most popular Go projects by GitHub stars. The complete code is available here.

The point here isn't to compare every framework on the market. Instead, the goal is to see how much boilerplate a framework removes compared with the hand-rolled versions from earlier parts, and where that convenience starts to cost you.

Router Setup and Route Registration

Gin doesn't impose an architecture like MVC. Its main type is the engine, which acts as both router and central object for the application. The gin.Default() call returns an engine pre-configured with crash-recovery and logging middleware.

router := gin.Default()
server := NewTaskServer()

router.POST("/task/", server.createTaskHandler)
router.GET("/task/", server.getAllTasksHandler)
router.DELETE("/task/", server.deleteAllTasksHandler)
router.GET("/task/:id", server.getTaskHandler)
router.DELETE("/task/:id", server.deleteTaskHandler)
router.GET("/tag/:tag", server.tagHandler)
router.GET("/due/:year/:month/:day", server.dueHandler)

Route registration follows a syntax similar to what we've seen before, but with Gin's own twists. Handlers no longer use the standard Go HTTP handler signature; they accept a single gin.Context, which provides access to both the request and the response writer. If you need to bridge standard handlers, Gin provides gin.WrapF and gin.WrapH helper functions.

Handlers Simplify, but Parameters Need Care

The most basic handler shows how much scaffolding disappears. With Gin, request logging is handled by default middleware, and JSON rendering is built into Context.JSON — no manual renderJSON helper required.

func (ts *taskServer) getAllTasksHandler(c *gin.Context) {
  allTasks := ts.store.GetAllTasks()
  c.JSON(http.StatusOK, allTasks)
}

Route parameters are where things get interesting. Gin exposes parameters declared with a colon prefix (like :id) through Context.Params.

func (ts *taskServer) getTaskHandler(c *gin.Context) {
  id, err := strconv.Atoi(c.Params.ByName("id"))
  if err != nil {
    c.String(http.StatusBadRequest, err.Error())
    return
  }

  task, err := ts.store.GetTask(id)
  if err != nil {
    c.String(http.StatusNotFound, err.Error())
    return
  }

  c.JSON(http.StatusOK, task)
}

But there's a catch: Gin routes do not support regular expressions. If your route matching needs are non-trivial, you'll end up writing more parsing and validation code by hand.

Request Binding

createTaskHandler demonstrates Gin's binding infrastructure — parsing request bodies (JSON, YAML, etc.), validating them, and mapping them onto Go structs. This particular example uses a rudimentary form without validation, but more advanced options exist.

func (ts *taskServer) createTaskHandler(c *gin.Context) {
  type RequestTask struct {
    Text string    `json:"text"`
    Tags []string  `json:"tags"`
    Due  time.Time `json:"due"`
  }

  var rt RequestTask
  if err := c.ShouldBindJSON(&rt); err != nil {
    c.String(http.StatusBadRequest, err.Error())
    return
  }

  id := ts.store.CreateTask(rt.Text, rt.Tags, rt.Due)
  c.JSON(http.StatusOK, gin.H{"Id": id})
}

The handler is noticeably shorter than earlier versions because ShouldBindJSON handles the parsing. For building responses, Gin offers gin.H, an alias for map[string]interface{}, which eliminates the need for one-off response structs.

The Cost of Convenience

Beyond routing and JSON handling, Gin ships with common middleware, authentication helpers, and HTML template rendering. For simple cases, these features save a significant amount of code compared with a standard-library approach.

The trade-off emerges when a framework limit becomes a blocker. If a router package like Gorilla's mux doesn't work out, swapping it for another router is a localized change. But if a no-regexp routing limitation in Gin turns out to be critical, replacing Gin means restructuring the entire application built on top of it.

This isn't an argument against frameworks — it's an observation about their pervasiveness. Frameworks make their limitations more significant precisely because they touch every part of your code.