>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #2948570. --> Reported by: [richgerdes](https://www.drupal.org/user/3437973) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>The doc module routes are currently statically defined for the default supported modules. This is limiting and results in redundant classes naming. These should be refactored into dynamically generated routes using plugins.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <h4 id="summary-proposed-resolution-plugins">Plugins</h4> <p>In <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/openapi/-/work_items/2874877" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/openapi/-/work_items/2874877</a></span>, we introduced plugins for managing generators. Implemented a plugin for docs modules could provide dynamic functionality and allow other ui type modules to be built around the openapi specs.</p> <h4 id="summary-proposed-resolution-routes">Routes</h4> <p>Using plugins for generators allowed us to convert the routes for the downloads into a single dynamic route with a dynamic param. Using plugins for the doc uis we can achieve a similar simplicity. A single route could be provided by core, which would take both a generator and a doc plugin and produce the same result.</p> <p>The only challenge presented by the current implementation is that the SwaggerUi module provides two different implementations. For Jsonapi, it provides a single url for details on all endpoints. However, for REST it provides a url for each for each of the available entity types. This means that a plugin type design is not available here.</p> <p>This per entity implementation however is an interesting thought. Since we already allow filtering of the download doc based upon entity, this functionality can be preserved by allowing the same filter params to be added to the generic doc for the rest+swagger docs ui. That filter chunk can then be passed to the download controller and the output can be used to display the docs. This allows us to generate the range of doc pages while limiting the number of routes that we are generating. This also allows us to extend this function into the json api docs. Additionally if we implemented this in a top level controller, we could also extend this into the reDoc module as well.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ol> <li>Replace Doc urls with unified route, using the <a href="https://www.drupal.org/project/openapi_ui">OpenAPI UI</a> module.</li> <li>Remove the ReDoc and Swagger modules, as they have been replaced.</li> <li>Developer installation steps to remove the old modules and install the new modules, if they are present. If not, we want to alert the user and fail the database update the admin either installed the new library or uninstalls the module via another method.</li> <li>Publish a Change Record and Release to remove this feature.</li> </ol> <h3 id="summary-ui-changes">User interface changes</h3> <p>We will be eliminating the <code>swagger_ui.rest.list</code> route and replacing it with extended filtering functionality. We may wish to provide either a similar listing page or to provide a filter option on the actual page to allow the user to select the filter params for the ui. This will as a result eliminate the need for <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/openapi/-/work_items/2874891" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/openapi/-/work_items/2874891</a></span>.</p> <h3 id="summary-api-changes">API changes</h3> <p>This will not result in any critical changes to the api, but will provide more extensible resources for module developers to extend the openapi functionality.</p>