| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Add a REST API hook that allows disabling specific endpoints
or rejecting specific requests, similar to ApiCheckCanExecuteHook.
Bug: T383011
Change-Id: I8518cb1ad7f00594c9f31d7bf934b1ce74f18da9
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Same as Ia294bf4 did for 1-line comments. This patch removes slightly
more complex 2-line PHPDoc comments that don't add any new information
to the code, but literally repeat what the code already says.
They say "don't document the code, code the documentation", and we
are doing this more and more. We just tend to forget to remove the
obsolete comments.
Note I'm also removing a line of text in a few cases when it's very
short and literally says the same as the method name. Again, such
comments add zero new information.
Change-Id: I01535404bab458c6c47e48e5456403b7a64198ed
|
| |
|
|
|
|
|
|
| |
The discovery endpoint provides basic information about accessing the
wiki's APIs, as well as a directory of available modules.
Bug: T365753
Change-Id: I161aa68566da91867b650e13c8aadc87cd0c428c
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In order to replace certain /api/rest_v1 endpoints, we
need to have something in MediaWiki that generates a compatible
responser. The MediaWiki REST API error format does not match
RESTbase. So the easiest approach seemed to be to
add a compatibility mode, triggered using the x-restbase-compat
header. This can be set via the gateway when rerouting the request.
Bug: T374136
Change-Id: I73934940d367be52941bd27861c248ab5bcfb5d2
|
| |
|
|
|
|
|
|
| |
The generated OpenAPI spec should contain information from the info
section of module spec files.
Bug: T366834
Change-Id: I488f550adbf32205bdcdcb59b1e7f5273643bf69
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This splits RouteFileModule into two classes, ExtraRoutesModule and
SpecBasedModule.
ExtraRoutesModule has no module prefix and supports
only "flat" route definition files and additional routes from
extension.json.
SpecBasedModule represents a single module defined in a definition
file similar to an OpenAPI spec. The idea is that a full OpenAPI spec
can be generated by filling in any missing information based on
information provided by the Handler implementation. In particular, the
definition of parameters and request body schemas will be generated.
A JSON schema for the new file format is added under docs/rest/.
Support for the intermediate format introduced in Iebcde4645d4 is
removed. It was not included in a release and was not being used outside
core tests.
Bug: T366837
Change-Id: I4ce306b0997f80b78a3d901e38bbfa8445bed604
|
| |
|
|
|
| |
Bug: T359364
Change-Id: I3646140ee8e16800c43f37958fc4b6ff00edcad6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Iebcde4645d472d2 I broke the way we generate metrics keys from
endpoint paths. Instead of using the declared paths with placeholders,
we were recording the actual paths, resulting in an explosion of metrics
keys.
This moves metrics logging from Router into Module, where the declared
path is available. This patch also introduces regression tests for the
issue.
Bug: T365111
Change-Id: I2c9ddfe6e28aaecd313356894f17033e2db59073
|
|
|
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
|
