Page MenuHomePhabricator

Generate OpenAPI descriptions for Lift Wing APIs
Closed, ResolvedPublic

Description

Request: Production inference services available via the Lift Wing API should generate OpenAPI descriptions (OADs) that comply with the OpenAPI specification.

Currently, Lift Wing API reference documentation is only available as manually-created pages on api.wikimedia.org (the "API Portal"), which is planned for deprecation (T415293): https://api.wikimedia.org/wiki/Lift_Wing_API/Reference.

The ML team may need to do a research spike to identify how and whether generating OADs can be accomplished for each of the inference services running on Lift Wing, since the models have varying input requirements and output structures. It's also unclear how KServe versions may impact the ability to auto-generate OAS-compliant OADs.

Timing

We are targeting June 10 to shut down the API Portal, so the Lift Wing API docs need to be published to a new location ideally by June 1 to allow for time to set up redirects.

Project plan

  • Create OpenAPI docs for non-revscoring Lift Wing endpoints
    • Tech Docs review and edits
  • Add the OpenAPI docs to the REST Sandbox on Test Wiki T426081
  • Validate the docs on Test Wiki
  • Publish the docs to a production wiki (either Wikitech, Meta, and mediawiki.org)
  • Create OpenAPI docs for revscoring endpoints
    • Tech Docs review and edits
  • Redirect API Portal docs to new locations

Project context

As part of the WE5.5 APP KR, the MediaWiki Interface and Technical Documentation teams are working with API maintainers to evolve how we build and surface Wikimedia APIs. This includes work bring our API descriptions into alignment with the OpenAPI specification, which enables standardized, generated, and testable API reference documentation. (strategy doc (Google doc, restricted access) | TechBlog post).

We are also working towards deprecating the API portal (T415293), which requires moving API documentation from there to more sustainable locations, and (ideally) for teams to start generating OpenAPI descriptions to produce that API reference documentation (T416586).

Investigations so far

In discussions with @DPogorzelski-WMF , @AikoChou, and @Sucheta-Salgaonkar-WMF, we hypothesized that upgrading the KServe version being used by our current inference services would then enable service owners to just run a simple command to enable the KServe "out of the box" support for OpenAPI.

  • Issue: Upgrading KServe is non-trivial (T380723, T380722, T367048), and we don't actually know for sure if that would enable auto-generation of OpenAPI-compliant API descriptions for Lift Wing inference services. More research is needed (see below for what the tech docs team did so far to research this.) Update: Upgrading KServe is unrelated to this work per T419455#11893320

@KBach did some initial exploration and tried to generate an OpenAPI description for the Revscoring goodfaith model, but was not able to successfully do that because of:

  1. Unclear/incomplete KServe documentation about "out of the box" support for OpenAPI
  2. Variations in response structure depending on request parameters make the API potentially incompatible with OpenAPI description format.

See full notes in Google doc.

The Link Recommendation API is an example of an ML model-based service (not running on Lift Wing infra) that complies with OpenAPI: see T415312 and https://gerrit.wikimedia.org/r/plugins/gitiles/research/mwaddlink/+/refs/heads/main/swagger/linkrecommendations.yml

Related Objects

Event Timeline

TBurmeister set Due Date to Apr 19 2026, 4:00 AM.Mar 9 2026, 6:38 PM
apaskulin changed Due Date from Apr 19 2026, 4:00 AM to May 30 2026, 12:00 AM.Apr 21 2026, 5:28 PM

The out-of-the-box openapi docs that kserve provides are bloated and reference a lot of endpoints that either not used or not working (e.g v2 endpoints). On top of that it doesnt provide yaml specs (just json).
The kserve upgrade as reference above has nothing to do with this work. What is related though is that kserve /v1 endpoints (the ones that are currently used) do not offer the ability to make POST requests through the UI as noted also in the kserve docs. This is only available in v2 endpoints which is currently something we have not migrated to. This migration would be a separate discussion as some of the functionalities of v1 are not supported in v2 (for example the inferece batcher on which we heavily rely in tone check).
To keep things simpler and easier to use we will :

  • commit the OpenAPI specs in yaml format the inference-services repository under /docs for the endpoints, starting with the ones that are publicly available. This will also solve the fact that {model_name} parameter cannot be replaced in the default kserve swagger UI and needs to be provided by the user.
  • to deal with the unpleasant fact that services don't have a common input/output schema we will provide prefilled request examples in the yaml docs as it is commonly done in swagger UIs.

Hi @isarantopoulos, thanks for the update!

On top of that it doesnt provide yaml specs (just json).

From a compatibility perspective, our OpenAPI systems support both JSON and YAML. Most of our existing OpenAPI specs use JSON, but if you prefer YAML, feel free to use that.

The kserve upgrade as reference above has nothing to do with this work.

Great! I'll remove that from the task description.

What is related though is that kserve /v1 endpoints (the ones that are currently used) do not offer the ability to make POST requests through the UI as noted also in the kserve docs.

I went ahead and tested a public, api.wikimedia.org Lift Wing POST endpoint in Swagger UI using the anonymous example from the docs, and the API request successfully returned the expected response. Unless I'm missing something, this means that a complete OpenAPI spec for the public Lift Wing endpoints will work in Swagger UI even though the endpoints are v1 and POST. Maybe the kserve docs are referring to using the OpenAPI spec for calls to the local kserve API?

commit the OpenAPI specs in yaml format the inference-services repository under /docs for the endpoints

Would this be one API spec in the repository or multiple specs, such as one under each model directory?

we will provide prefilled request examples in the yaml docs as it is commonly done in swagger UIs

Are you planning to add these manually?

Change #1285735 had a related patch set uploaded (by Gkyziridis; author: Gkyziridis):

[machinelearning/liftwing/inference-services@main] OpenAPI specs: Create /docs with openapi specs in yaml format for models.

https://gerrit.wikimedia.org/r/1285735

Hey @apaskulin thnx for your update.

Would this be one API spec in the repository or multiple specs, such as one under each model directory?

I think it would be better to have a /docs directory on the top level of the repo where we can add/configure examples and openapi specs for the all of the models.

Are you planning to add these manually?

We created examples for request/response so they are autofilled in the UI.

Test it locally:

  1. Pull the patch
  2. Spin up Swagger UI locally: `docker run -p 8081:8080 -e SWAGGER_JSON=/docs/openapi.yaml -v $(pwd)/docs:/docs swaggerapi/swagger-ui
  3. Browse the specs at: http://localhost:8081 and Try Out

SwaggerUI-edit-check (3,428×2,090 px, 390 KB)
Try Out (3,426×1,870 px, 404 KB)

Next Steps

Since the openapi specs are tested in a Swagger UI, we believe that we can use them in the Rest Sandbox.
The /docs/{model}.yaml files can be fetched directly from the gerrit repo into the Rest Sandbox.
We decided to use .yaml files in order to be more legibly and comprehensive.

I went ahead and tested a public, api.wikimedia.org Lift Wing POST endpoint in Swagger UI using the anonymous example from the docs, and the API request successfully returned the expected response. Unless I'm missing something, this means that a complete OpenAPI spec for the public Lift Wing endpoints will work in Swagger UI even though the endpoints are v1 and POST.

This is tested by @apaskulin and by me (in the comment above) using a Swagger-UI, so we can move forward and test how we can use these yaml files in the Rest Sandbox.

I went ahead and tested a public, api.wikimedia.org Lift Wing POST endpoint in Swagger UI using the anonymous example from the docs, and the API request successfully returned the expected response. Unless I'm missing something, this means that a complete OpenAPI spec for the public Lift Wing endpoints will work in Swagger UI even though the endpoints are v1 and POST. Maybe the kserve docs are referring to using the OpenAPI spec for calls to the local kserve API?

@apaskulin the limitation refers to swagger UI as served by kserve (the out-of-the-box capability). There we have the limitation of not being able to make requests through the UI. That is why we chose to generate the specs manually so that the docs will be complete. It adds a bit of maintenance but it is more user friendly and we also don't have to delve into extending the current limitations of kserve.

Change #1285735 merged by jenkins-bot:

[machinelearning/liftwing/inference-services@main] feat(openapi-specs): Add OpenAPI specs for publicly available Lift Wing models.

https://gerrit.wikimedia.org/r/1285735

I created a subtask for configuring the openapi specs in the mediawiki-config: https://phabricator.wikimedia.org/T426081
I will paste there my findings.

Change #1287445 had a related patch set uploaded (by Alex Paskulin; author: Alex Paskulin):

[machinelearning/liftwing/inference-services@main] openapi: Copyedits and style fixes

https://gerrit.wikimedia.org/r/1287445

Change #1287445 merged by jenkins-bot:

[machinelearning/liftwing/inference-services@main] openapi: Copyedits and style fixes

https://gerrit.wikimedia.org/r/1287445

Change #1288879 had a related patch set uploaded (by Gkyziridis; author: Gkyziridis):

[machinelearning/liftwing/inference-services@main] feat(openapi-specs): Clean docs and align edit-check/langid schemas with real server responses

https://gerrit.wikimedia.org/r/1288879

Thanks for your responses. That all sounds good!

Thank you for creating the OpenAPI files, @gkyziridis! This is a big step towards completing this work, and they are looking great.

It looks like we still need to document the Revscoring endpoints. I don't know of a way to document the response schemas for these endpoints in OpenAPI since the keys vary depending on the response, but we should still be able to add response examples. I think this will be sufficient for these endpoints.

We will also need to incorporate the /translation endpoints from https://api.wikimedia.org/service/lw/recommendation/api/docs.

Change #1288879 merged by jenkins-bot:

[machinelearning/liftwing/inference-services@main] feat(openapi-specs): Clean docs and align edit-check/langid schemas with real server responses

https://gerrit.wikimedia.org/r/1288879

Hey @apaskulin, thnx for your comments.
We are still figuring out how we will expose the openapi-specs docs.
We decided to go first with the current models that are configured in /docs and avoid revscoring/ORES models with (multi-wiki pattern) for now. We will discuss about them in a second iteration.

We decided to go first with the current models that are configured in /docs and avoid revscoring/ORES models with (multi-wiki pattern) for now. We will discuss about them in a second iteration.

Do you have an idea of when the second iteration would be? We are targeting June 10 to shut down the API Portal, so the Lift Wing API docs need to be published to a new location ideally by June 1 to allow for time to set up redirects. I'm happy to help with adding the revscoring endpoints to the OpenAPI docs to help meet this timeline. Alternatively, we could migrate the API Portal docs to pages on Wikitech, which I'd also be happy to help with.

Change #1293768 had a related patch set uploaded (by Alex Paskulin; author: Alex Paskulin):

[machinelearning/liftwing/inference-services@main] docs: Add OpenAPI docs for Revscoring endpoints

https://gerrit.wikimedia.org/r/1293768

I've gone ahead and started working on a patch to add the Revscoring endpoints to the OpenAPI docs: https://gerrit.wikimedia.org/r/c/machinelearning/liftwing/inference-services/+/1293768

I'll continue to add to the patch throughout the week, but I wanted to share it here for visibility and to avoid duplicating work.

Hi @apaskulin thnx for your work in the openapi-specs, it is much appreciated.
Based on the discussion we had in this slack-thread and after investigating multiple options, we ended up to add these /docs yaml files in the mediawiki-config repository under the /static/liftwing-openapi-specs/ directory, I filed this patch for doing that.
When this patch is merged and deployed, then we can add the rest specs for the models over there.
I updated the https://phabricator.wikimedia.org/T426081 task left a comment for the latest changes: {T426081#11963339}

Change #1299635 had a related patch set uploaded (by Alex Paskulin; author: Alex Paskulin):

[machinelearning/liftwing/inference-services@main] docs: Organize endpoints into tags

https://gerrit.wikimedia.org/r/1299635

Change #1293768 merged by jenkins-bot:

[machinelearning/liftwing/inference-services@main] docs: Add OpenAPI docs for Revscoring endpoints

https://gerrit.wikimedia.org/r/1293768

Change #1299635 merged by jenkins-bot:

[machinelearning/liftwing/inference-services@main] docs: Organize endpoints into tags

https://gerrit.wikimedia.org/r/1299635

Change #1300229 had a related patch set uploaded (by Alex Paskulin; author: Alex Paskulin):

[machinelearning/liftwing/inference-services@main] docs: Add translation endpoint and fix tags

https://gerrit.wikimedia.org/r/1300229

Change #1300229 merged by jenkins-bot:

[machinelearning/liftwing/inference-services@main] docs: Add translation endpoint and fix tags

https://gerrit.wikimedia.org/r/1300229

apaskulin assigned this task to gkyziridis.
apaskulin updated the task description. (Show Details)

The Lift Wing OpenAPI docs are now live in production: https://wikitech.wikimedia.org/w/index.php?api=lift-wing&title=Special%3ARestSandbox 🎉 A huge thank you to @gkyziridis for all his work on this!