With the potential for multiple handlers to overload a URL, it can be difficult to determine where a request will be routed internally. We currently use a rule of forwarding a request to the next routing layer if the URL did not change, but this is pretty subtle and not terribly intuitive.
In cases when we know for certain where we want a request to be handled (e.g. at the storage layer, or by a service handler, etc.) it helps to be able to specify a URL that will trigger that handler (e.g. `/_syt/service/`, `/_sys/bucket/`, `/_sys/table/`, etc.).
For this task, let's identify handlers that can be pulled out of the overloaded namespaces, and assign them more intentional URL patterns. Those can then also be used directly in error messages and metrics.
## Candidates
- `/v1/{domain}/_sys/service/`: services like parsoid etc (already implemented)
- `/v1/{domain}/_sys/bucket/`: bucket layer, often backed by tables in `_tables`.
- `/v1/{domain}/_sys/table/`: table storage layer; currently implicitly handled in `storage.js`
## Request routing
With this in place, we can syntactically prevent external requests from hitting internal entry points. All access will instead be mediated and documented by external handlers, which will in most situations forward requests to the bucket layer.