Refactor routing into middleware-api-operation model

[RobbeSneyders]

This PR refactors the routing middleware into the middleware-api-operation model already used in the security middleware.

This model is often used in the API community and should be a good basis for any middleware that needs to act on an operation level.

[coveralls]

Pull Request Test Coverage Report for Build 2297034892

• 30 of 30 (100.0%) changed or added relevant lines in 4 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage decreased (-0.0007%) to 94.336%

---

Files with Coverage Reduction	New Missed Lines	%
connexion/handlers.py	1	82.61%

Totals
Change from base Build 2270753938:	-0.0007%
Covered Lines:	2698
Relevant Lines:	2860

---

💛 - Coveralls

[Ruwann]

Thanks!
Do you have a concrete reference to which also use this pattern? I'd be interested to see some other examples. I don't think I fully understand the change in this PR yet.

[RobbeSneyders]

Do you have a concrete reference to which also use this pattern? I'd be interested to see some other examples. I don't think I fully understand the change in this PR yet.

It's used by:

• Flask: App - Blueprint - Route
• Starlette: App - Router - Route
• Django: Project - App - View
• Connexion: App - API - Operation

In its simplest form, it's just a hierarchical set of routers. I think this is a lot easier to follow than the default_fn and call_next functions we had before. Especially if we repeat this pattern across our middlewares.

[Ruwann]

Alright, thanks for the clarification!