Page MenuHomePhabricator

[5.5.3 Milestone]: Create "Beta" module for testing endpoints
Open, Needs TriagePublic

Description

Description

We will start by creating a new ‘preview’ or ‘beta’ flag that can be used on API requests to intentionally opt in. For now, we assume this approach will be a 'vBeta' (or similar) pattern included within the endpoint route. We believe that introducing an intentional flag will help address an observed gap, where current endpoints are documented as being unstable or experimental, yet end up being used in production applications.

We will then test these mechanisms by introducing new versions of some MediaWiki REST API endpoints that will demonstrate some of the new consistent usage patterns that we are driving towards. The initial endpoints will reflect changes that we are relatively confident in, or which have industry standard practices that we may follow (eg: pagination, error message structure).

Conditions of acceptance

  • Align on routing patterns for surfacing 'beta' endpoints
  • Generate an OpenAPI spec for 'beta' endpoints
    • 'Beta' should appear as its own module within the REST Sandbox. For now, this will appear as a single module.
    • Once more modules are released, we may assume that each module may have a 'live' and 'beta' version.
  • Create at least 1 'Beta' endpoint that reflects new patterns for:
    • Pagination
    • Versioning
    • Consistent error messages

Event Timeline

HCoplin-WMF renamed this task from [5.2.3 Milestone] Create "Beta" module for testing endpoints to [5.5.3 Milestone]: Create "Beta" module for testing endpoints.Apr 16 2025, 1:41 PM

Related discussion about a similar proposal here: T366567: REST: introduce audience designations (proposal), for context.

Would the beta module be assumed (by virtue of being named "beta") to contain only beta endpoints? Or would it also need to have a "vbeta" version, to follow the new pattern? If the latter, how does this url look to you?

Personally, I dislike it.

Exposition:

For illustration, I'm speculating we might create a beta version of PageHistoryHandler, which currently uses "older_than" and "newer_than" parameters to page through results (and for sake of example, I'll keep that parameter naming below, even though we may change it).

The current url invoking that handler looks something like (this actually works right now, none of the other urls below do):

If we were invoking this as part of an imaginary "history" module instead of using the default module, it might look something like:

That seems okay.

If we created a beta version of that endpoint in a "beta" module, with version "vBeta", it'd look something like:

That seems weird.

Alternatively, we could create speculative module names, and if they only had beta endpoints under them, then changing/removing them would be low consequence. A url under this pattern might look like:

This means that, for any endpoint currently in the default module that we want to experiment with, we'd need to come up with a proposed actual module name, rather than being able to just drop it into a "beta" module. But I like that, as it lets us experiment with module names in a visible but non-committal way. The sooner we get everything out of the "default" module, the better. And creating a catch-all module for beta endpoints feels like an anti-pattern.