New input/query API

[manucorporat]

I want to provide a better API to get the input parameters from the path, POSTForm and GETForm.

Let's say, we register this route:

router.POST("/user/:username", handler)

and we expect to receive requests like this:

POST /user/manu?page=10 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: localhost:8080

email=manu.mtza%40gmail.com

• Includes a parameter in the path (:username)
• Includes a GET form parameter (page)
• Includes a POST form parameter (email)

Right now, you would have to do this in order to get the parameters:

func handler(c *gin.Context) {
    c.Request.ParseForm()

    name := c.Params.ByName("username")
    page := c.Request.Form.Get("page")
    email := c.Request.PostForm.Get("email")
}

• Inconsistent
• Low level (c.Request.ParseForm())
• Difficult to learn

The new proposal:

func handler(c *gin.Context) {
    name := c.Input.FromPath("username")
    page := c.Input.FromGET("page")
    email := c.Input.FromPOST("email")
}

Also, c.Input will implement an intelligent Get() method that takes the value from the proper source. This feature is implemented in popular frameworks like laravel.

router.GET("/account/:id", func(c *gin.Context) {
        // same than  c.Input.FromPath("id") in this context
    id := c.Input.Get("id")

    // ... read account with id
}

---

GET /list?page=2

router.GET("/list", func(c *gin.Context) {
        // same than  c.Input.FromGET("page") in this context
    page := c.Input.Get("page") // page = 2
}

One more thing, c.Input can be printed directly with fmt.Print() providing a useful debugging tool.

fmt.Println(c.Input)

[itsjamie]

@manucorporat, I'd like to make the request that ParseForm is lazily called on the first call that requires it.

[manucorporat]

@itsjamie of course! ParseForm would be lazily called

[itsjamie]

@manucorporat This definitely reduces the amount you need to directly call on the net/http methods.

If you don't mind me asking, what do you feel the cost to the framework is for introducing this functionality?

What is the benefit?

I really like how Gin currently focuses on providing a nice implementation of handling middleware, and provides some convenience method for oft-used functionality that has a slightly nicer API than the underlying tech (like httprouter). I just want to make sure that any code you decide to add to part of core is following the vision you want the project to take.

[itsjamie]

Personally, I feel this is right in line with what I feel Gin should accomplish (btw).

[manucorporat]

@itsjamieI totally agree with you.

If you don't mind me asking, what do you feel the cost to the framework is for introducing this functionality?

This new API will have 0 overhead, otherwise I would not include it!

• Request handing and router path can not slowed down
• 0 memory allocation policy

What is the benefit?

Gin focuses in a good balance of performance and convenience. A typical request in httpRouter can be handled in 220ns (in my machine), Gin only adds 30ns of overhead in average.

But as you know, Gin provides an much nicer environment: middlewares, content negotiation, parsing, validation....

I want to continue optimizing the most common use cases such us the user input through a form, and I think we need a better API for that.

[leedstyh]

Will the intelligent one c.Input.Get() cause some secure issue like XSS?

[manucorporat]

@leedstyh I dropped this feature because it introduces very complex situations.

[thinkerou]

As @manucorporat say, we should close the issue, right? @appleboy

[appleboy]

@thinkerou OK.