Page MenuHomePhabricator

Plan deployment of API docs
Closed, ResolvedPublic

Description

The AQS 2.0 services will generate one OpenAPI specification per service. The resulting specs will be published to each of the code repositories at docs/swagger.json. To make these docs publicly accessible, we need to define a strategy to:

1. Serve the spec file

Serve each specs so that it is accessible via a public URL. (For example, at https://api.wikimedia.org/pageviews/api-spec.json) Currently, the OpenAPI spec is stored in the git repo of each service.

Alternatively, we could do in-memory generation at runtime and emit caching headers such that we effectively store the generated file in Varnish rather than it being a deployed file, but we haven't investigated this option.

2. Serve the HTML docs

Serve an HTML view of the spec using RapiDoc as shown in the example below. (For example, at https://api.wikimedia.org/pageviews/api-docs). This doesn't necessarily have to be handled by the service. As long as the raw spec file is publicly available, a minimum viable option could be to create a subpage of https://api-spec-reader.toolforge.org/ that preloads a given spec.

RapiDoc example

<!doctype html> 
<html>
  <head>
    <meta charset="utf-8"> 
    <script type="module" src="https://unpkg.com/rapidoc/dist/rapidoc-min.js"></script>
  </head>
  <body>
    <rapi-doc
      spec-url = "ADD SPEC URL HERE"
      theme = "dark"
      schema-style="table"
      fill-request-fields-with-example="false"
      primary-color="#049DFF"
      font-size="large"
    >
    </rapi-doc>
  </body>
</html>

Event Timeline

Hi @hnowlan, Bill suggested I ping you for your thoughts on this or to point us towards the right person to ping.

We would like to serve the raw API spec for Device Analytics in a publicly accessible location. I was thinking of adding an endpoint to Device Analytics that would serve the file at /api-spec.json, similar to this endpoint from the Link Recommendation service. Does this sound like a reasonable approach?

Hi @hnowlan, Bill suggested I ping you for your thoughts on this or to point us towards the right person to ping.

We would like to serve the raw API spec for Device Analytics in a publicly accessible location. I was thinking of adding an endpoint to Device Analytics that would serve the file at /api-spec.json, similar to this endpoint from the Link Recommendation service. Does this sound like a reasonable approach?

Yep, sounds good to me! It'd be cool if we could standardise on a filename to do this with cross-service within the gateway, but that's a bit outside the scope of this ticket.

Thanks, @hnowlan! I agree about the standard filename within the gateway.

@BPirkle I've opened T333593 to add the endpoint.

@SGupta-WMF Considering that the endpoint to serve the spec will need to be unique for each of the different services, we'll need to decide on a convention for the routes. After talking this over with Bill, we were thinking it would be best to serve one spec per service at /service-name/api-spec.json. For example: /device-analytics/api-spec.json. Does this sound reasonable to you?

Decided on /service-name/api-spec.json (for example: /device-analytics/api-spec.json) per T333593#8861889

VirginiaPoundstone claimed this task.

This work is complete. There are some fixes that need to be done, but it will be part of the larger overall documentation epic T288664: AQS 2.0 user documentation.