Change Details

5.2.8b [API Module Refinement] If we create onboard at least 3 more API modules demonstrating a variety of use cases (at least 1 stand-alone service API, 1 feature team owned extension API, 1 internal module), we will be able to refine usability and set the foundation for the future of the API Platform. ### Background Over the course of FY 25/26, we introduced the concept of API modules and began rolling out initial versions. ### Problem statement As we are approaching this work iteratively, the currently implemented API modules are limited in scope and complexity. Through implementing those modules, we learned a lot and have identified opportunities where we need to improve usability for API managers, as well as ### Impacted users API builders and maintainers: The frameworks and toolsets for building APIs are changing. We expect teams to both build new APIs using our standards, as well as revisit existing APIs to raise the bar on compliance. API users: As we expand module adoption, API user experiences will change. First, REST Sandbox experiences will shift such that individual modules must be navigated to from the dropdown, instead of viewing within the flat list. Additionally, as audiences are introduced, URL patterns and structures will change. For now, we will try to avoid breaking changes and will only follow the new patterns on new APIs; however, as new versions and consolidation efforts get underway, more expansive breaking changes may be necessary. ###Scope [] AQS/Analytics API specs included in API explorer [] Wikibase/Wikidata specs included in API explorer where extension is installed [] Implement public, beta, and internal audience designations [] At least 2 additional teams define and own modules & specs for extension APIs [] Improve REST API token management [] Update API module documentation [] Refine implementation based on external team feedback [] [Stretch] Tech design for restricted audience designation ### Out of Scope This body of work does not include migrating all extensions to the API module framework. We will treat additional migrations as a stretch goal, which can be covered by future essential work. [Copied from Asana]

> 5.2.8b [API Module Refinement] If we create onboard at least 3 more API modules demonstrating a variety of use cases (at least 1 stand-alone service API, 1 feature team owned extension API, 1 internal module), we will be able to refine usability and set the foundation for the future of the API Platform. ### Scope### Background Over the course of FY 25/26, we introduced the concept of API modules and began rolling out initial versions. ### Problem statement As we are approaching this work iteratively, the currently implemented API modules are limited in scope and complexity. Through implementing those modules, we learned a lot and have identified opportunities where we need to improve usability for API managers, as well as ### Impacted users API builders and maintainers: The frameworks and toolsets for building APIs are changing. We expect teams to both build new APIs using our standards, as well as revisit existing APIs to raise the bar on compliance. <TBD>API users: As we expand module adoption, API user experiences will change. First, REST Sandbox experiences will shift such that individual modules must be navigated to from the dropdown, instead of viewing within the flat list. Additionally, as audiences are introduced, URL patterns and structures will change. For now, we will try to avoid breaking changes and will only follow the new patterns on new APIs; however, as new versions and consolidation efforts get underway, more expansive breaking changes may be necessary. ###Scope [] AQS/Analytics API specs included in API explorer [] Wikibase/Wikidata specs included in API explorer where extension is installed [] Implement public, beta, and internal audience designations [] At least 2 additional teams define and own modules & specs for extension APIs [] Improve REST API token management [] Update API module documentation [] Refine implementation based on external team feedback [] [Stretch] Tech design for restricted audience designation ### Out of Scope This body of work does not include migrating all extensions to the API module framework. We will treat additional migrations as a stretch goal, which can be covered by future essential work. [Copied from Asana]