Whether to expand the Portal to cover APIs not proxied through the Gateway or whether to change the concept if the Gateway as a set of curated APIs

The outcome we want to provide is to enable API producers to discover ALL APIs, including net new and existing APIs which are currently not proxied through the gateway.

In order for this to happen, I don't think we have to proxy everything through the API gateway, however, there are benefits if we do.

If all APIs are proxied through the API gateway, there's value in having a centralized source to measure usage and performance, as well as apply consistent policies to all APIs such as rate-limits and authorization. My understanding is that we would not need to change the base URLs for existing APIs (e.g. Action API) thus I wouldn't imagine any interruption to downstream users. However, I'm not clear what implications come with this change. Maybe a question to @hnowlan?

Whether we proxy all APIs through the gateway or not, I do believe all our APIs should be discoverable via the API Portal. I assume it'd be linking out to external API documentation (leveraging the "Discover more APIs" section) for things like the Action API, WMEnterprise, etc.

In T289183#7292820, @sdkim wrote:

Whether to expand the Portal to cover APIs not proxied through the Gateway or whether to change the concept if the Gateway as a set of curated APIs

The outcome we want to provide is to enable API producers to discover ALL APIs, including net new and existing APIs which are currently not proxied through the gateway.

In order for this to happen, I don't think we have to proxy everything through the API gateway, however, there are benefits if we do.

If all APIs are proxied through the API gateway, there's value in having a centralized source to measure usage and performance, as well as apply consistent policies to all APIs such as rate-limits and authorization. My understanding is that we would not need to change the base URLs for existing APIs (e.g. Action API) thus I wouldn't imagine any interruption to downstream users. However, I'm not clear what implications come with this change. Maybe a question to @hnowlan?

If a service internally responds on endpoint.wikimedia.org/myservice/whatever (or on endpoint.discovery.wmnet/whatever internally), we can make any API gateway endpoint query (api.wikimedia.org/service/myservice/whatever) it with appropriate headers and endpoints as if it were being accessed on its original URL.

If we were to consider the api gateway answering directly/seamlessly to public requests for endpoint.wikimedia.org/myservice (as in users request that URL directly and it transparently goes via the API gateway, applies rate limiting etc) I think we'd need to think long and hard about that because it's a pretty big change of pattern - but I think that's not what we're talking about here right?

If we were to consider the api gateway answering directly/seamlessly to public requests for endpoint.wikimedia.org/myservice (as in users request that URL directly and it transparently goes via the API gateway, applies rate limiting etc) I think we'd need to think long and hard about that because it's a pretty big change of pattern - but I think that's not what we're talking about here right?

Sorry for creating confusion here! I didn't intend to imply a change of scope to the API Gateway. Edits task description

The outcome we want to provide is to enable API producers to discover ALL APIs, including net new and existing APIs which are currently not proxied through the gateway.

Thanks, @sdkim! This is what I needed. Based on this, I think I do recommend including API producers in the use cases for the API Portal. How's this:

API Portal mission statement
The API Portal is an information hub for API producers and consumers to discover, consume, and manage Wikimedia APIs.

Personas

• API producers
• API consumers
• Technical writers
• Product managers

Capabilities

• Allow for the discovery of ALL (new, old, experimental, public, internal, Gateway, non-Gateway, WMF, non-WMF) Wikimedia HTTP APIs through an API catalog
• Serve API reference documentation created using the to-be-developed API Platform documentation tooling
• Act as a multilingual wiki for API-related learning materials, like tutorials and best practices
• Create and manage Wikimedia OAuth 2.0 clients (carried over from the existing API Portal scope)

Fantastic, thanks @apaskulin