> My idea is that if you do e.g. a taxi app, then the only ‘routes’ you should care about are routes on the map. There are no routes on the map. As a backend

> My idea is that if you do e.g. a taxi app, then the only ‘routes’ you should care about are routes on the map. There are no routes on the map. As a backend developer, your job is to define what are the valid routes and how to handle non-compliance but valid requests. Take for example content negotiation. Do you honour the Accept header or do you serve content based on the request path, such as the resource extension? What should you do if you receive a request where both approaches are used but in a contradicting manner? Now, keep in mind that API versioning is handled as content negotiation. Now, let's add auth to the mix. Do you intend to hand-roll a few OpenId connect workflows by hand, which involve 3 or 4 HTTP requests behind exchange between 2 or 3 actors? Are you intending to hand-roll token expiration checks? Or do you prefer to use an API key or session cookies, or any other, or a mix of all of them put together? And what about caching? Are you expecting to check and tweak cache control and etags headers each and every time you receive a request? Or do you only want to receive a request and act upon it's request body? If you use one of these web frameworks, all you need to do is configure your middleware to specify how you handle auth and cache and content negotiation, define routes based on the outcome of your content negotiation process, and proceed to implement your web API.