[erlang-questions] Pattern-matching function?

[Steve Vinoski]

On 10/30/08, anders conbere <aconbere@REDACTED> wrote:
>  To illuminate a bit, I'm writing a mochiweb app and hating life
>  because I haven't found a good way to reduce the amount of noise
>  created by the gargantuan case statement created by splitting up the
>  url.

I don't use mochiweb so I can't comment on that, but with yaws I use
separate functions to handle each URI as described here:

<http://www.infoq.com/articles/vinoski-erlang-rest>

In my experience breaking the handlers into different functions makes
them more convenient to deal with. I'd be very surprised if you
couldn't do something similar with mochiweb.

(An aside: Joe Armstrong and I were wondering back at Erlang eXchange
in July: maybe this is a dumb question but how do you actually
pronounce "mochiweb" -- is it "mo-chee-web" or "mo-key-web" or
"mock-key-web" or ...?)

>  When writing web applications like this in python, there are
>  often some nice tools provided to at least make the matching list of
>  routes more readable (see, routes, django urls, werkzeug etc.). Many
>  of these actually use regexes or a matching techniques that I could
>  also use in erlang, it just feels like a shame that matches aren't
>  more readily available as first class citizens.

If you own the URIs, then you can make them as friendly as you want
for the function arg matching approach described above. Some people
downplay the design of URIs as being relatively unimportant, and from
a client POV they're correct because a RESTful server is responsible
for supplying the client with URIs embedded within hypermedia
responses to drive the client through its application state, which
means the client doesn't really need to care about the "shape" of the
URIs. But from a server perspective, I disagree that URI design is
unimportant -- if you design your URIs well, it definitely eases the
difficulties of tying them to their underlying resource
implementations.

If you don't own the URIs, then matching can be a lot more problematic
if the URIs are poorly designed. For example if they all use the same
path and rely on query strings with lots of parameters for
differentiation, then you're best off isolating their parsing into a
function that effectively rewrites the URIs into something more
friendly, and then dispatching them on that basis.

I personally haven't seen any cases where I needed regexp URI matching
for my RESTful web service implementations, but I acknowledge your
mileage may vary.

--steve