00:01 My hapi server is set up on port 8000. I have one route, whose handler simply replies with the path params from the request.
00:12 The route is listening for gets on the server's route. If I change the path to /users, and change the URL in my browser to include /users, I get the same empty object response, letting me know that the route is working incorrectly.
00:28 I'll add /1234 to the end of the URL. The hapi server returns not found because there is no matching route. I can add /1234 to the end of the route, and it will work again. But what I really want to do is make this portion of the path a parameter. Using a simple brace notation, I'll update the path to accept a user ID instead of a hard coded route.
00:54 Now when I refresh the browser, the object is no longer empty. It includes a key and a value for user ID. The user ID parameter can be made optional by inserting a question mark just after the parameter name. Now when I refresh the browser, I still see the user ID param. But if I remover the user portion of the path from the URL, the route is still matched and I get an empty object back.
01:17 Path parameters do not have to be in the last segment of the path. I'll remove the question mark from the param and append /files to the path after the parameter. Then request /users/1234/files from the browser, and the user ID param is returned as expected.
01:37 Path params only match a single segment of a path from one slash to another. However, hapi's router supports a wildcard notation that can be used to match any number of segments with a single parameter. Inserting an asterisk after the parameter name signifies that it is a wildcard parameter.
01:55 Now, when I request /file/a/b/c.jpeg, the file's parameter contains the remainder of the URL where the wildcard was placed. The number of matching segments can also be specified by adding a number after the asterisk. If I append a two after the asterisk, my URL will no longer match the route since it has three segments, a, b and c.jpeg.
02:19 Removing one of the segments allows the URL to match the router once again. Hapi also supports matching partial segments. If I want to restrict matched files to only jpegs, I can add .jpeg after the parameter and it match something like a.jpeg, returning a as the value of the parameter.
02:39 The last thing I'd like to cover is path specificity. Hapi's router evaluates routes in order from most specific to least specific, which means that the order routes are created does not affect the order they are evaluated. To demonstrate, I'll copy my existing route and then change the first one to be a wildcard route. It's the least specific path possible.
03:04 If hapi evaluated routes in the order they were defined, every request would match this first route instead of the second. When I refresh the browser, it matches the second more specific route. I'll change the URL to show the wildcard route will match anything that doesn't match the second route.