|
| 1 | +# 7) Wikibase REST API work-in-progress endpoints {#rest_adr_0007} |
| 2 | + |
| 3 | +Date: 2023-02-01 |
| 4 | + |
| 5 | +## Status |
| 6 | + |
| 7 | +accepted |
| 8 | + |
| 9 | +## Context |
| 10 | + |
| 11 | +At the time of writing, Wikibase REST API endpoints are not defined by default when loading the Wikibase extension. Endpoints are defined by developers configuring them in the [`routes.json`] file and Wikibase admins adding the file to the [`$wgRestAPIAdditionalRouteFiles`] mediawiki configuration variable. We also maintain an [OpenAPI Definition] of the Wikibase REST API which, among other things, is used to create visual and interactive documentation hosted on [doc.wikimedia.org][swagger-docs]. During development, new endpoints need to be defined in the route file and OpenAPI Definition before they can be considered ready for use, as they need to be available on local instances, CI systems, and test systems (e.g. Beta Wikidata). |
| 12 | + |
| 13 | +As well as configuring what endpoints are defined in mediawiki, a route file also configures which factory method (or handler class) should be used. This means a route file is coupled with the implementation. For example, renaming a factory would also require updating the route file to match. So, while you can enable multiple route files with `$wgRestAPIAdditionalRouteFiles`, it is **not** recommended to have the _same_ endpoint configuration duplicated in multiple route files. In other words, the route file should not be used as a mechanism for Wikibase admins to configure which endpoints are defined. |
| 14 | + |
| 15 | +We were concerned that deployers of the REST API would want control over what endpoints are defined. The stakeholders we spoke to aren't currently concerned about this and are happy for us to decide what endpoints are defined and when. There is also a desire from some stakeholders to have the same endpoints enabled across all Wikibase instances in order to provide consistent functionality. |
| 16 | + |
| 17 | +REST API endpoints can also be defined by adding them to an extension's JSON configuration file ([`extension-repo.json`] in this case) under `"RestRoutes"` (see [REST_API/Extensions#Defining_routes]). This might be the best place for production-ready endpoints in the future, once the REST API is no longer 'v0' and considered stable, as they can be enabled by default when the Wikibase extension is loaded. WIP endpoints can still be enabled where needed (e.g. CI and test systems) via `$wgRestAPIAdditionalRouteFiles`. |
| 18 | + |
| 19 | +How to manage new features or changes to existing endpoints are outside the scope of this ADR. |
| 20 | + |
| 21 | +## Decision |
| 22 | + |
| 23 | +- We will maintain two route files stored in the `repo/rest-api` directory of the Wikibase extension: |
| 24 | + - `routes.json` that will contain routes completed to a functional state |
| 25 | + - `routes.dev.json` that will contain WIP routes which is meant for local development, CI, and test systems |
| 26 | +- We will mark WIP routes in the OpenAPI Definition with a `[WIP]` prefix in the summary and `This endpoint is currently in development and is not recommended for production use.` in the description. |
| 27 | +- Wikibase admins should not create their own route files or modify the existing ones |
| 28 | + |
| 29 | +## Consequences |
| 30 | + |
| 31 | +- We have control over the route files and can update them at the same time if any factory methods change |
| 32 | +- The Wikibase REST API can still be enabled separately to the Wikibase extension |
| 33 | +- Wikibase admins can decide which route file(s) they want to enable via the [`$wgRestAPIAdditionalRouteFiles`] configuration option |
| 34 | +- All Wikibase instances that have enabled the REST API via the `Wikibase/repo/rest-api/routes.json` file will have the same routes available. Wikibase admins will have limited control over what routes are enabled and when. This is good for consistency across the Wikibase ecosystem. |
| 35 | +- Wikibase admins that create their own route file risk broken routes if our factories change. |
| 36 | +- We will be able to add new routes to the OpenAPI definition before they are ready, while still indicating the status of each route. |
| 37 | + |
| 38 | +[doc.wikimedia.org]: https://doc.wikimedia.org |
| 39 | +[`extension-repo.json`]: https://gerrit.wikimedia.org/g/mediawiki/extensions/Wikibase/+/758065e4967fcb9575a06302a80a84ccb762d373/extension-repo.json |
| 40 | +[OpenAPI Definition]: https://swagger.io/specification/ |
| 41 | +[REST_API/Extensions#Defining_routes]: https://www.mediawiki.org/wiki/API:REST_API/Extensions#Defining_routes |
| 42 | +[REST_API#Versioning]: https://www.mediawiki.org/wiki/API:REST_API#Versioning |
| 43 | +[`routes.json`]: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/758065e4967fcb9575a06302a80a84ccb762d373/repo/rest-api/routes.json |
| 44 | +[semantic versioning]: https://semver.org/ |
| 45 | +[swagger-docs]: https://doc.wikimedia.org/Wikibase/master/js/rest-api/ |
| 46 | +[wikidata.org]: https://www.wikidata.org |
| 47 | +[Wikidata:REST_API]: https://www.wikidata.org/wiki/Wikidata:REST_API |
| 48 | +[`$wgRestAPIAdditionalRouteFiles`]: https://www.mediawiki.org/wiki/Manual:$wgRestAPIAdditionalRouteFiles |
0 commit comments