Skip to content

Permit multiple externalDocs #1034

Open

Description

Documenting APIs often depend on multiple external factors - functional and non-functional aspects, change notes, governance, strategy, many more - and a single externalDocs reference is often insufficient, especially in complex scenarios where multiple parties are responsible for design/deployment/delivery of these aspects (not everyone is DevOps)

Would we want to move the single object to an array/collection of objects:

externalDocs:
- description: link 1
  url: http://link/1
- description: link
  url: http://link/2

or

externalDocs:
  link1:
    description: link 1
    url: http://link/1
  link2
    description: link
    url: http://link/2

Gong further, form 2 may also benefit from becoming a reference:

externalDocs:
  link1:
    url: http://link/1

paths:
  /path1:
    get:
      externalDocs:
      - $ref: '#/externalDocs/link1'

While some of this may overlap with (the single) externalDocs avaulable in a tag, it is not entirely overlapping, and the link should ideally reside close to where it is needed instead of tracking it back through a tag that may not be immediately apparent will contain the required link.

Activity

  1. whitlockjc commented on Apr 11, 2017

    @whitlockjc
    Member

    I could see this being useful.

  2. darrelmiller commented on Apr 13, 2017

    @darrelmiller
    Member

    I think I would be tempted to point to single HTML file that had links to other docs from there. I think if we start trying to describe different kinds of external docs in OpenAPI we are going to quickly run into a set of requirements for metadata about those docs.

  3. webron commented on Apr 19, 2017

    @webron
    Member

    Marked as post 3.0. We may or may not implement it, but 3.0 is feature complete and this request is not critical enough to break that.

  4. added this to the milestone on Apr 21, 2017
  5. micheldumontier commented on Oct 26, 2017

    @micheldumontier

    Would very much like to be able to make a list. in the bioinformatics/life science community community, it's always nice to add links to published work about the API

  6. rstavchansky commented on Apr 30, 2018

    @rstavchansky

    I would use this suggested feature to point users to specific example workflows. We have more than one per endpoint.

  7. fernando-ck commented on Jul 29, 2019

    @fernando-ck

    I'd also like to have this feature implemented. Our documentation is based on multiple resources which would be useful if put on the same list.

  8. nogates commented on Jul 30, 2019

    @nogates

    FWIW, I always found strange that the key was actually named externalDocs (plural) but only one link was allowed.... I think it would make sense to go with the externalDocs map object

  9. kholmukhamedovme commented on Dec 5, 2019

    @kholmukhamedovme

    @webron any updates since 19 Apr 2017 when you marked this enhancement as post 3.0?

  10. webron commented on Dec 8, 2019

    @webron
    Member

    @kholmukhamedovme no additional work was done about this, likely as it did not attract a lot of attention compared to other issues. That said, anyone in the community can make a proposal to push this forward if they find it's important enough. More information can be found at https://github.com/OAI/OpenAPI-Specification/blob/master/DEVELOPMENT.md.

  11. pjungermann commented on Jan 28, 2020

    @pjungermann

    another alternative: use Markdown to add links to the description field(s). It is probably not as elegant and not as machine readable as the suggested solution above, but you can still provide the information you want, organized as you want. Tooling might have different support for this, but as long as they support some Markdown, basic links should work.

  12. Gypsying commented on Nov 23, 2020

    @Gypsying

    how is going now ?

  13. 1 remaining item

  14. shaedrich commented on Apr 6, 2022

    @shaedrich

    multiple external factors - functional and non-functional aspects, change notes, governance, strategy, many more

    Maybe, it would be helpful to add a type (but that might(!) imply (but not necessarily require) metadata as @darrelmiller pointed out) property for the aforementioned factors alongside with a label

    another alternative: use Markdown to add links to the description field(s). It is probably not as elegant and not as machine readable as the suggested solution above, but you can still provide the information you want, organized as you want. Tooling might have different support for this, but as long as they support some Markdown, basic links should work.

    @pjungermann There is another issue, pointing out using $ref property under description: #1402

  15. xaviqo commented on Sep 29, 2022

    @xaviqo

    Bumping this. I also think this would be useful.

  16. y4my4my4m commented on Feb 7, 2023

    @y4my4my4m

    Bump, needed this feature today.

  17. darrelmiller commented on Feb 7, 2023

    @darrelmiller
    Member

    @y4my4my4m Would it be possible to provide examples of how this would have been useful for you? We should definitely revisit this issue in moonwalk.

  18. y4my4my4m commented on Feb 7, 2023

    @y4my4my4m

    @darrelmiller

    Some payload are used by both client and server and I'm trying to give reference to both.

    In some cases I'm providing links to multiple examples as well (for different use cases).

  19. suguiura-pp commented on Nov 14, 2023

    @suguiura-pp

    I think externalDocs should accept zero, one, or more external documents, since development teams might need to gather multiple business documents or even domains to consolidate an API.

    Is there any reason why this field accepts only zero or one "externalDoc" so far?

  20. added
    metadatatags, info, license, contact, markdown usage, etc.
    and removed on Feb 8, 2024
  21. added this to the v3.3.0 milestone on Oct 14, 2026
  22. handrews commented on Oct 14, 2026

    @handrews
    Member

    @lornajane has a proposal for this in PR #5467.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementmetadatatags, info, license, contact, markdown usage, etc.re-use: ref-group-combineRe-use requests involving grouping components and combining groups

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions