Best practices for shared components

[craicoverflow]

What would be considered best practice when it comes to shared components in OpenAPI? Is it acceptable for multiple different schemas to be relying on an external source, which could be changed silently and break your OpenAPI schema?

Another option would be to have a custom Spectral ruleset which expects certain components to be defined in your OpenAPI.

I personally prefer the latter option using Spectral. It would make the schema more readable, and does not rely on an internet connection.

Maybe this is something that could be used in apicurio-studio.

cc @jsenko

[EricWittmann]

We would like to support custom validation rules in Studio - that has been on the wishlist for awhile. That would allow users to set up their custom ruleset to ensure that all of their APIs conform to some company-defined standards.

With that in place, $ref becomes less risky. I definitely think a standard set of common data types and responses, centrally managed and referenced/consumed from multiple APIs, is extremely useful. One additional feature that we have on our list for Studio is the ability to tag/label a specific moment in time for an API design. Basically a very simple approach to versioning, where users can say "this moment in time is called 2.0.7" - that tag/label is then immutable and we can support $ref pointers to a specific moment in time that cannot change.