@ferluk it feels like a bummer if you're accustomed to leveraging the order of declared paths as it's implemented in other routing libs, but with gin you can consider flipping the conflicting route.

r.GET("/price/drivers", ctrl.GetDriversPrice)
r.GET("/drivers/:id", ctrl.AuthRequired, ctrl.GetDriver)

Unfortunately it sometimes means that routes which feel like they should hang off the same Group sharing a set of common middleware can't, and our middleware usage can become repetitive like below where ctrl.AuthRequired is repeated twice (unless moveable to a higher group)...

priceRoutes := r.Group("/price").Use(ctrl.AuthRequired)
{
  priceRoutes.GET("/drivers", ctrl.GetDriversPrice)
}

driverRoutes := r.Group("/drivers").Use(ctrl.AuthRequired)
{
  // cannot hang export off of driveRoutes due to conflict with /:id
  // driverRoutes.GET("/price", ctrl.GetDriversPrice)
  driverRoutes.GET("/:id", ctrl.GetDriver)
}

However I still think this ^ is likely better than nesting routing logic for pricing in another handler, ideally route definitions can inform of all url routing rather than overloading handlers with route logic which has been suggested by others.

Another option is to increase the specificity of your drivers/:id endpoint...

r.GET("/drivers/price", ctrl.GetDriversPrice)
r.GET("/drivers/id/:id", ctrl.AuthRequired, ctrl.GetDriver)

That ^ may feel less congenial to the typical restful pattern of resources/:resourceID but at least grouping middleware is a bit cleaner...

v1 := r.Group("/v1").Use(ctrl.AuthRequired)

driverRoutes := v1.Group("/drivers").Use(ctrl.DriverMiddleware)
{
  driverRoutes.GET("/price", ctrl.GetDriversPrice)
  driverRoutes.GET("/id/:id", ctrl.GetDriver)
}

Routes Hierarchy #957

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions