Good way to match on methods and paths?

[mooreryan]

(This is more of a question, so perhaps it would be better on discuss forum or something like that.)

I see in this pull request (https://github.com/anuragsoni/routes/pull/92/files) that there was once support for also matching on http method/verb. What is the recommended way to handle the http verbs now?

I have a bunch of routes that look like this:

let about = 
  let path = s "about" /? nil in
  let handler = function
    | `GET -> Server.respond ...
    | _ -> Server.respond `Method_not_allowed 
  in
  path @--> handler

then all those go into one router with one_of and then matching done with the match'. That's okay, but it's a bit backwards from what I might expect (eg ASP.NET minimal api).

Example

app.MapGet("/", () => "This is a GET");
app.MapPost("/", () => "This is a POST");
app.MapPut("/", () => "This is a PUT");
app.MapDelete("/", () => "This is a DELETE");

Alternatively, I could imagine something where you might have a associative map that maps verbs to a router (each set up with one_of, then you have some set up where you match first on the verb, and then do the route matching with match'.

I suppose it is a mostly matter of personal preference, but I wanted to get your input since at one time this library also handled the http verbs.

[anuragsoni]

Hi!

Moving this to a GitHub discussion instead of an issue.

The library indeed had support for HTTP verbs for a while. I ended up removing that mostly because of a lack of consensus around a http types library in the OCaml ecosystem 😅 That, and as you mention there can be multiple different approaches one can take for this use-case. In the past I've used a couple of different approaches to deal with these scenarios:

Using a map with http verbs as keys and Routes.router as a value

The following examples assume that one's using base with https://github.com/anuragsoni/shuttle_http but the same can be done without either one of these libraries:

(* I'd typically have a function that accepts an assoc list of http verbs and
    convert them into a Map of the following type *)
type 'a routes = 'a Routes.route list Map.M(Meth).t

(* example of routes *)
  let routes =
    Map.of_alist_multi
      (module Meth)
      [ ( `GET
        , (s "hello" / s "world" /? nil)
          @--> fun (_ : Request.t) ->
          return (Response.create ~body:(Body.string "Hello World")) )
      ; ( `GET
        , (s "sum" / int / int /? nil)
          @--> fun a b (_ : Request.t) ->
          return (Response.create ~body:(Body.string (Printf.sprintf "%d" (a + b)))) )
      ]
  ;;

(* From here on the router will be another map where the values are converted from a list of routes
    to a Routes.router *)
let router = Map.map routes ~f:Routes.one_of

(* Then a utility function that can drive the matching by performing
    lookups on the http verb map, and forwarding the query to Routes
    if a verb lookup succeeds.  *)
let match_route verb path =
    match Map.find router verb with
    | None -> return (Response.create `Method_not_allowed)
    | Some router ->
      (match Routes.match' router ~target:path with
       | ...)
  ;;

Single router with functions that modify a http service

This second approach is something that I've been using more of in the past couple of years. For this I define the http services with a type: type handler = Request.t -> Response.t Deferred.t, and keep a single router that maps from routes to handlers.

let with_methods : Meth.t list -> handler -> handler =
  fun methods handler request ->
  if List.mem methods (Request.meth request) ~equal:Meth.equal
  then handler request
  else return (Response.create `Method_not_allowed)
;;

I define a function like with_methods and then defining a route like about looks something like so:

let about =
  (s "about" /? nil)
  @--> with_methods [ `GET ] (fun request -> Server.respond ...)
;;

But yeah, a lot comes down to personal preferences! Some might prefer the first approach to responds with a 405 if a verb isn't in the map (even if the incoming path pattern wouldn't have matched any existing routes), and some might prefer the second approach where one can respond with a 404 if the path pattern wouldn't match any route, and let the with_methods decide when to respond with a 405. Oh and I think either one of these approaches could be paired with a builder layer on top to mimic the DotNet api you linked to (I kinda like the look of it!), where one might keep a mutable assoc list of routes and calling get, post etc on the app structure appends a new route to the list, and then run could create a final router and drive the matching using either one of the approaches linked above.

[mooreryan]

Thanks for the response! The first thing you show with the maps is essentially what I had tried...it's pretty good. I will definitely be trying the second way you show as well and compare...it has a nice simplicity.