Having routes in the Pool

Feature
1

Rational

As we’d like to make routes modifiable by implementors we need to put them in Pool in order to reuse the patterns people already know of register object by their __name__ in the pool and the possibility to override it in custom modules.

Another issue with the current route design is that they are available even when the module is not activated. Accessing them would result in an error but it leaks some information that might be valuable.

Proposal

Our proposal is to add routes into the pool.

  • Adding a new type in the Pool: route
  • Objects will be registered in the Pool by their __name__
  • Just like we register methods in __rpc__, those object will contain a mapping named __routes__ between a couple (endpoint, HTTP Verb) and a Route object
  • This Route object will represent:
    • The name of the method to call when accessing the route
    • A list of decorators to apply on the method (eg: auth_required, etc).
  • The URL will be composed as follow: /<database>/<__name__>/<endpoint>

At the end of the initialization of a database pool a process will define in Werkzeug all the available routes.

It might happen that a request to a route will be the event that initialize the pool (and thus the routes are not known yet), in this case instead of raising a 404, we should initialize the pool and then replay the request.

1 Like
2

I think those objects should be named router and Router .

I think it will be better to use the method name as key and a list of decorator as value.

We need to remove the routes on Pool.stop.

I think it will be good to have a fixed prefix before <__name__> as we have now already rpc and rest.

It is probably simpler to have a catch all route for any database and all the possible route and return a 503 with a Retry-After and initialize the pool.

3

Here’s the MR: Add routes to the Pool (!3396) · Merge requests · Tryton / Tryton · GitLab