Does a RequestHandler know which Rule/Route was invoked?

[daves...@gmail.com]

I am working on connecting instrumentation of RequestHandlers with their OpenAPI operation IDs.  The Operation IDs tend to differ based on request method -- usually something like getWidgetById for GET or updateWidget for PATCH.  I want to do this by naming the Rule/Route using the Operation ID since they are semantically the same.

AFAICT, the route information is lost long before the RequestHandler instance is created.  Am I missing something?

If there isn't any way to do this today, should I open an issue to add one?

A little background, I am working on sending metrics to a graphite/statsd backend using the OpenTelemetry.io stuff along with integrating with a co-workers OpenAPI request validation library.  Historically we've used the request handler class name and request method to "name" the operation in metrics .  This has a number of draw backs that I am trying to remove -- most notably, refactoring and renaming request handler classes results in changes to dashboards or requires that we manually rename whisper files.

Thanks, Dave.

[Pierce Lopez]

In a RequestHandler method, you can access self.request.path - does that have what you need? I suppose you may use regex to capture some path components as variables, and you'll want the "generic" form of the path.

You can also do self.application.reverse_url(...) but that requires knowing what variable path components exist so you can pass the substitutions. Perhaps you can inspect the handler method to get the generic path variable components you want like "<id>" or ":id" etc.

- Pierce

--
You received this message because you are subscribed to the Google Groups "Tornado Web Server" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-tornad...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python-tornado/918d59d7-3340-4970-bade-b34919f5b4d4n%40googlegroups.com.

[Ben Darnell]

On Sun, Feb 28, 2021 at 8:09 AM daves...@gmail.com <daves...@gmail.com> wrote:

I am working on connecting instrumentation of RequestHandlers with their OpenAPI operation IDs.  The Operation IDs tend to differ based on request method -- usually something like getWidgetById for GET or updateWidget for PATCH.  I want to do this by naming the Rule/Route using the Operation ID since they are semantically the same.

AFAICT, the route information is lost long before the RequestHandler instance is created.  Am I missing something?

No, you're not missing anything. This is not preserved in the older URLSpec style of routing at all, and in the newer tornado.routing system it's not preserved out of the box (it's also ambiguous in this scheme - there can be multiple nested layers of routing; do you want every layer or just the innermost?). But since you're talking about routing based on request method (which Tornado doesn't really do), I'm not certain I'm following your question correctly. Could you give a more concrete example?

 

 

If there isn't any way to do this today, should I open an issue to add one?

I think what I'd do is use a custom subclass of tornado.routing.Rule (or tornado.routing.Matcher?) to do the routing you require and add something to target_kwargs to capture the identity of the rule in whatever form you need and pass it on to the handlers. Adding this in a general and backwards-compatible way may be tricky but within your application you can coordinate between your rules and your handlers.

-Ben

 

A little background, I am working on sending metrics to a graphite/statsd backend using the OpenTelemetry.io stuff along with integrating with a co-workers OpenAPI request validation library.  Historically we've used the request handler class name and request method to "name" the operation in metrics .  This has a number of draw backs that I am trying to remove -- most notably, refactoring and renaming request handler classes results in changes to dashboards or requires that we manually rename whisper files.

Thanks, Dave.

--