Likewise, a deployment engineer should not have to worry about the particular resources being served by an application. In other words, the interface between application and server should be as simple as possible, and url routing just makes more sense in the web framework because the application developer wants control over the resources and how to reach them.
However, what I was trying to suggest is something slightly different. What if a web framework was smart enough to generate a routing configuration for a web server, instead of processing some sort of route table on every request? Think of a workflow like this:
1. Application developers can still define routes somewhere in application code as they do now.
2. Framework takes that route table, and generates a routing config for a web server, offline.
3. Deployment engineer does not need to worry about resources being served, but would have to make sure that the generated config is included where appropriate and trigger configuration reload on web server.
I (naively) think, that the above three could result in:
1. Nothing really changes for the application developer, except a chunk of redundant code is removed from the top of his code in the stack.
2. Web server configuration languages (or a subset related to routing) are fairly robust by now and rarely drastically change (I'm thinking about nginx and Apache2 here). Add this to an auto-generated configuration and a layer of error is reduced.
3. Deployment engineer does not need to configure any routing, but has to make sure a generated file is included in configuration, when deployed.