| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
The "mapping" field that contains the map of elements in the path is now
private and can be accesed via the RouteParams function.
|
| | |
|
| |
|
|
|
|
| |
Instead of letting the matching function creates the response object,
it's created earlier with a default HTTP status of 200, and the object
is passed to the function.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Try to clean up messy path (too many slashes for now) in the path before
applying the Match.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
`foom` is now the web framework, so the code from mooh.go has been moved
to that repository.
The response and request are handled by the new `web-request` project,
and so the code has been moved to this repository.
|
| |
|
|
|
| |
This test was failing because it was expecting the list to be ordered,
but that's not the case.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
When the user call `AddNotAllowed` on the router, for each path, a new
route will be added for each HTTP method not existing. The new route
returns a 405 HTTP error and a header containing the list of allowed
HTTP methods.
|
| |
|
|
|
| |
The AddOptions method on the Router creates a route to respond to the
OPTIONS request, and list all the supported HTTP methods for the given route.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The HasPath method check if a path is know by the router and return a
boolean.
The RemovePath method is useful to remove dynamically a path from the
router.
The GetAllRoutesByMethods returns a list of routes that match a given
method.
I'm not sure I'll keep all those methods available since there's no
immutability on the routes, and I don't want the user to mess with
them. We will see later.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is the format supported for URI templates (RFC 6570). We're not
using it now but this is something that I consider for a near future.
|
| | |
|
| |
|
|
| |
This function return a list of path known by the router.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a route is created with a Default:
&Route{
Path: "/user/:id",
Defaults: map[string]string{
"id": "1",
},
...
}
a request for /user/ will match the route, and set the value for "id" to
1. However, the route /user will not match.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The dispatcher is renamed router (as for the test file) and the
router_test is renamed to route_test (since that's what this file is
supposed to test).
|
| |
|
|
| |
This is for future performances' regressions.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
By adding validations, it's possible to create without ambiguity routes
like "/user/:id" and "/user/:name", where the validation for the name
will check that it's an number, and name is a string.
A validation is not required for every key. However, you can't specify
a validation for a key that does not exist in the URL. The validation
use Regexp for now, and the user has to create the regexp with the
function MustCompile.
Some utility functions are added to easily gain information about a
component, validator, etc. This will be extended more soon.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
There's no need to expose directly the list of routes inside the router,
we will provide an interface to that later.
Also, when adding a new routes, we verify that the route don't already
exist, and if it's the case, we return an error.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, to create a route, a user would call the AddRoute function,
and pass three arguments (the path, the HTTP method and the function).
This interface is way too limited if we need/want to expand what a route
is in the future.
Instead, we keep calling the AddRoute function to create a route, but
this time the user pass a Route structure. The AddRoute will then
apply a few transformations and connect the route to the router.
|
| |
|
|
|
|
| |
By keeping a map of the HTTP methods available for a given route, we
don't have to iter over a list of executors when we try to find if the
request match, we can quickly check if the methos is set to true.
|
| |
|
|
|
|
|
|
|
|
|
| |
There's no need to split the URL in components every time we call the
Match function on a Route. We can split it once in the dispatcher and
then path the array to the function.
Sadly, this makes the interface a little bit weaker, since we have to
pass the HTTP method and the list instead of the full HTTP Request. I
think in the future we should pass our own HTTP request object, with the
split already in done in this one.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Parameters can come from the URL, but also the query string or the
body. For now we create a function ParamRoute to be explicit about
which param we want.
|
| | |
|
| |
|
|
|
| |
Some logic will be needed to create this object, it's easier to do that
with a constructor.
|
| |
|
|
|
|
| |
In the case of an optional components, the name is ":something". We
need to normalize that name in order to be able to call directly
"something" when needed.
|
| | |
|
| |
|
|
|
|
|
|
| |
Forward the http.Request object to the Dispatcher's Match function, and
instead of returning the route that match, return the whole Match
object.
We create our own Request object later in the process.
|
| | |
|
| |
|
|
|
| |
Don't mess with the first / for now, we will see later if we need to
change it.
|
| |
|
|
|
|
|
|
|
| |
For some path, more than one route can match. We try hard to
disambiguate them, and if we can't, we return an error with the list of
routes matching the request.
In order to do that, the Match function needs to be able to also return
an error in addition to a route.
|
| |
|
|
|
|
| |
If a component in the path starts with "?:", it means that it's
optional. We then store the lenght of the components without those
optional parameters.
|
| | |
|
| | |
|
| |
|
|
| |
If a path starts with /, remove it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating a new route, check if the URL contains some elements with
a ":" in it. If that's the case, it means that this component is a
parameter. For now we consider that all the parameters are required,
but in the future we should support optional parameters (starting with a
?).
When dispatching a request, verify if the element in the url is a
parameter and store it in the response.
When a route match a request, a Match structure is returned with some
information (path that matched, the route, the HTTP method, etc.).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For now the framework provide a "dispatcher" and a mechanism to add
routes. The type "route" provide a constructor so some logic can be
applied before creating the type.
The way the dispatcher works for now is very stupid: it looks for all
the registered routes, and check if it's the right HTTP method and if
the patch matches.
The next step is to deal with place holder in the path.
|
|
|
This is yet another web framework in golang. I'm using it as a
playground for ideas and concept. I've no idea if this will be one day
useable.
|
