Modules group together endpoints by a shared prefix. The idea is that each module has its own version and can generated self-contained self-documentation. This allows clients to have clear expectations about the endpoints of each module, no matter what wiki they are accessing. So far, each wiki may be exposing a different set of endpoints, with no way to provide a spec that describes that set of endpoints in a way that would be consistent across wikis and stable over time.
Bug: T362480
Change-Id: Iebcde4645d472d27eee5a30adb6eee12cc7d046b
Allow a greater variety of status codes to be handled by
HttpException, including 204 and 304 ("no content" and "not modified")
as well as 301, 302, 303, 304, and 307 (redirects, via a new
RedirectException subclass). This allows for a greater variety of
"exceptional conditions" to be handled by throwing, avoiding the need
for checking error codes all the way up a deeply nested call stack.
For cases which still aren't covered, we allow wrapping a full
Response object as an exception. This allows the same basic exception
mechanism to be used, even if sometimes you need a custom status code
or custom headers.
See I800a3fe5160a9d7fc3fddbb445ec61cc5390b14f for a sample use case
from the Parsoid REST handler implementation.
Bug: T260959
Change-Id: I5a00ba8fbc90aa266a6d77f15e8e398be5463ff4
