In addition to on_get(), on_post(), etc, could we allow redefining the default responders via a generic on_request()?
This idea is borrowed from the Responder framework (which is in turned inspired by Falcon and Flask), see: Class-Based Views.
Responder itself is sort of abandoned, so it was challenging to even get a test program running, but once I got it up, it seemed that providing both on_request() AND on_get() in Responder makes the said framework call both upon GET. Which IMHO doesn't fit well into Falcon's design, so maybe we could instead map on_request (if provided) only instead of the default responders. See also: https://github.com/falconry/falcon/issues/735.
Opinions welcome on what to do with on_options(), if not provided. Maybe we could still provide a default on_options(), and not use on_request() for that, in order to minimize the breaking impact of this change, and for convenience.
This change could potentially pave the way to further unifying resources and sinks, see also
In addition to
on_get(),on_post(), etc, could we allow redefining the default responders via a genericon_request()? This idea is borrowed from the Responder framework (which is in turned inspired by Falcon and Flask), see: Class-Based Views.Responder itself is sort of abandoned, so it was challenging to even get a test program running, but once I got it up, it seemed that providing both
on_request()ANDon_get()in Responder makes the said framework call both uponGET. Which IMHO doesn't fit well into Falcon's design, so maybe we could instead mapon_request(if provided) only instead of the default responders. See also: https://github.com/falconry/falcon/issues/735.Opinions welcome on what to do with
on_options(), if not provided. Maybe we could still provide a defaulton_options(), and not useon_request()for that, in order to minimize the breaking impact of this change, and for convenience.This change could potentially pave the way to further unifying resources and sinks, see also