Better handling of http router pattern
bsr
I am struggling a bit to register the http route to handle below
patterns. I am trying RESTful URL patterns as explained here (http://
microformats.org/wiki/rest/urls)
GET /people
--> this is possible with http.HandleFunc("/people", peopleHandler)
GET /people/new
--> this is possible with http.HandleFunc("/people/new",
peopleNewHandler)
POST /people
--> this can be done by filtering on request.Method of peopleHandler
switch r.Method {
case "GET":
//handle
case "POST":
I am having trouble with the below formats
GET /people/1
GET /people/1/edit
I could think about doing it through string manipulation in
peopleHandler to see whether these patterns matches..This gets messy
as the url becomes
GET /people/1/phones/23
etc.. Also, the same logic needs to repeat for other controllers like
GET /po
GET /po/1
etc..
I see two good web packages, twister and web.go. I think they allow
to use regex patterns rather than string for router handler
registration. I prefer not to use those packages as they implement
their own http packages, and prefer to stick with core. Any future
plans to improve easing the registration and retrieving url
parameters?
An example from twister (simple go wiki example)
Register("/<artnum:.*>", "GET", show, "POST", update)
id, _ := strconv.Atoi(req.Param.Get("artnum"))
Thanks.
Evan Shaw
> I see two good web packages, twister and web.go. I think they allow
> to use regex patterns rather than string for router handler
> registration. I prefer not to use those packages as they implement
> their own http packages, and prefer to stick with core. Any future
> plans to improve easing the registration and retrieving url
> parameters?
>
> An example from twister (simple go wiki example)
>
> Register("/<artnum:.*>", "GET", show, "POST", update)
>
> id, _ := strconv.Atoi(req.Param.Get("artnum"))
You can create a handler for this outside of the http package, which
is (IMO) where it belongs. I'm not even convinced that it belongs in
the core library, as there are many ways you can do URL routing and
none of them are standard. It's the kind of thing that there would be
lots of disagreement and bikeshedding about.
Here's a simple way to route with regexps that passes the parameters
as a slice of strings:
(warning: uncompiled/untested code lies ahead)
type route struct {
re *regexp.Regexp
handler func(http.ResponseWriter, *http.Request, []string)
}
type RegexpHandler struct {
routes []*route
}
func (h *RegexpHandler) AddRoute(re string, handler
func(http.ResponseWriter, *http.Request, []string)) {
r := &route{regexp.MustCompile(re), handler}
h.routes = append(h.routes, r)
}
func (h *RegexpHandler) ServeHTTP(rw http.ResponseWriter, r *Request) {
for _, route := range h.routes {
matches := route.re.FindStringSubmatch(r.RawURL)
if matches != nil {
route.handler(rw, r, matches)
break
}
}
}
For your case, you can do something like:
reHandler := new(RegexpHandler)
reHandler.AddRoute("/people/[0-9]+/edit$", peopleEditHandler)
http.ListenAndServe(":8080", reHandler)
- Evan
bsr
to be minimal, and your approach works for me.. this group is so
responsive, and thanks all...
Russ Cox
handler dispatch by default, because doing so makes it much
more difficult to resolve conflicts. The current path-based
mux will let you register for "/" to catch everything and
then "/foo" to catch just "/foo", and the latter takes precedence
over the former because it is a more specific match.
Defining "more specific" becomes significantly murkier
when the patterns are regular expressions instead of just
prefixes. It can be done, but it's expensive and the result
would probably not be easy to explain or predict in the
general case. The path-based mux scales better.
Of course, as Evan said, there's nothing stopping you from
writing your own regexp-based mux and registering it to
handle "/". That's part of the beauty of interfaces.
Russ
roger peppe
> Many regexp routers avoid the "more specific" problem by matching patterns
> in the order that the patterns are specified.
if you continue to allow the current Go approach
of allowing separate packages to register their
own http handlers (for example expvar), then this
can't work, as init functions are called in arbitrary
order.
Russ Cox
> Many regexp routers avoid the "more specific" problem by matching patterns
> because most or all of the routing for an application is
> specified declaratively by a list of regular expressons. Contrast this with
> ServeMux applications where routing logic is spread out through one or more
> handlers
indeed, and this is something we want to keep.
Russ Cox
>> if you continue to allow the current Go approach
>> of allowing separate packages to register their
>> own http handlers (for example expvar),
>
> problems with decentralized registration:
if you don't want to use the default handlers,
don't use the default servemux.
russ
