Routing - Starlette

Starlette has a simple but capable request routing system. A routing table is defined as a list of routes, and passed when instantiating the application.
The endpoint argument can be one of:
Paths can use URI templating style to capture path components.
You can use convertors to modify what is captured. The available convertors are:
Convertors are used by prefixing them with a colon, like so:
If you need a different converter that is not defined, you can create your own. See below an example on how to create a datetime convertor, and how to register it:
After registering it, you'll be able to use it as:
Path parameters are made available in the request, as the request.path_params dictionary.
Routes can also specify which HTTP methods are handled by an endpoint:
By default function endpoints will only accept GET requests, unless specified.
In large applications you might find that you want to break out parts of the routing table, based on a common path prefix.
This style allows you to define different subsets of the routing table in different parts of your project.
You can also use mounting to include sub-applications within your Starlette application. For example...
You'll often want to be able to generate the URL for a particular route, such as in cases where you need to return a redirect response.
URL lookups can include path parameters...
If a Mount includes a name, then submounts should use a {prefix}:{name} style for reverse URL lookups.
Mounted applications may include a path=... parameter.
For cases where there is no request instance, you can make reverse lookups against the application, although these will only return the URL path.
If you want to use different routes for the same path based on the Host header.
Note that port is removed from the Host header when matching. For example, Host (host='example.org:3600', ...) will be processed even if the Host header contains or does not contain a port other than 3600 (example.org:5600, example.org). Therefore, you can specify the port if you need it for use in url_for.
There are several ways to connect host-based routes to your application
URL lookups can include host parameters just like path parameters
Incoming paths are matched against each Route in order.
In cases where more that one route could match an incoming path, you should take care to ensure that more specific routes are listed before general cases.
If you're working at a low-level you might want to use a plain Router instance, rather that creating a Starlette application. This gives you a lightweight ASGI application that just provides the application routing, without wrapping it up in any middleware.
Use a non-negative max_body_size to limit the total number of request body bytes accepted by an application. The limit includes multipart file data and multipart encoding overhead. It defaults to None, which preserves the existing unlimited behavior.
Router and Mount also accept max_body_size. A limit on an inner route, mount, or router overrides the outer limit after routing. This allows an upload route to accept a larger body than the rest of the application.
Application middleware runs before routing. If such middleware reads the body, the application-level limit applies to those bytes before a route can raise the limit. Keep the application limit large enough for the largest legitimate route when using body-consuming application middleware.
Starlette counts the actual body bytes received from the ASGI server. Content-Length is used only to reject an oversized request early and is not trusted to enforce the limit. A reverse proxy request-body limit and a quota on temporary storage provide additional deployment-level safeguards.
When working with WebSocket endpoints, you should use WebSocketRoute instead of the usual Route.
Path parameters, and reverse URL lookups for WebSocketRoute work the same as HTTP Route, which can be found in the HTTP Route section above.
The endpoint argument can be one of: