-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs 10035 develop compat matrix prototype oas3 pa--DON'T CLOSE #94
base: latest
Are you sure you want to change the base?
Docs 10035 develop compat matrix prototype oas3 pa--DON'T CLOSE #94
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a first pass. I'd suggest to go through my initial set of suggestions, replace all the ?
with written descriptions based on either (or both) the corresponding descriptions in the RAML 1.0 spec or the OAS 3.0 spec and take it from there. I can then do one more pass and I would suggest we also ask each individual team to review and approve what's written in their product's column. Hope that makes sense.
…ttps://github.com/mulesoft/docs-general into DOCS-10035-develop-compat-matrix-prototype-oas3-PA
endif::[] | ||
:keywords: api, instance, manager | ||
|
||
You can implement your API specification in a way that best suits your needs. The following table explains how each of the features of the API specification is best implemented and the level of support provided for the specification in API Designer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can implement your API specification in a way that best suits your needs. The following table explains how each of the features of the API specification is best implemented and the level of support provided for the specification in API Designer. | |
You can implement your API specification in a way that best suits your needs. The following table explains how each of the features of the API specification is best implemented and the level of support provided for the specification in Anypoint Exchange. |
|=== | ||
| Feature: Description| RAML Implementation | OAS Implementation | Exchange Support | ||
4+| *Modularity:* The ability to break an API specification into reusable and shared units. | ||
| API Document: The main API specification description metadata, which is the entry point for the specification. | RAML root document | OAS root document | Allows publication and versioning of an API asset in Exchange console rendering. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| API Document: The main API specification description metadata, which is the entry point for the specification. | RAML root document | OAS root document | Allows publication and versioning of an API asset in Exchange console rendering. | |
| API Document: The main API specification description metadata, which is the entry point for the specification. | RAML root document | OAS root document | Allows publication and versioning of an API asset in Exchange console rendering. Additionally, advanced search is supported. |
| Feature: Description| RAML Implementation | OAS Implementation | Exchange Support | ||
4+| *Modularity:* The ability to break an API specification into reusable and shared units. | ||
| API Document: The main API specification description metadata, which is the entry point for the specification. | RAML root document | OAS root document | Allows publication and versioning of an API asset in Exchange console rendering. | ||
| Libraries: The unit containing collections of related reusable description elements. | RAML library | Can be implemented using an empty OAS specification containing multiple components. | Allows publication of a RAML API fragment asset. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Libraries: The unit containing collections of related reusable description elements. | RAML library | Can be implemented using an empty OAS specification containing multiple components. | Allows publication of a RAML API fragment asset. | |
| Libraries: The unit containing collections of related reusable description elements. | RAML library | Can be implemented using an empty OAS specification containing multiple components. | Allows publication of a RAML API fragment asset (only RAML). No console or advanced search is supported. |
4+| *Modularity:* The ability to break an API specification into reusable and shared units. | ||
| API Document: The main API specification description metadata, which is the entry point for the specification. | RAML root document | OAS root document | Allows publication and versioning of an API asset in Exchange console rendering. | ||
| Libraries: The unit containing collections of related reusable description elements. | RAML library | Can be implemented using an empty OAS specification containing multiple components. | Allows publication of a RAML API fragment asset. | ||
| Fragments: Stand-alone component of the specification that describes a specific element. | RAML fragment | Can be implemented using an empty OAS specification containing a single component.| Allows publication of a RAML API fragment asset. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto as the previous entry.
| API Document: The main API specification description metadata, which is the entry point for the specification. | RAML root document | OAS root document | Allows publication and versioning of an API asset in Exchange console rendering. | ||
| Libraries: The unit containing collections of related reusable description elements. | RAML library | Can be implemented using an empty OAS specification containing multiple components. | Allows publication of a RAML API fragment asset. | ||
| Fragments: Stand-alone component of the specification that describes a specific element. | RAML fragment | Can be implemented using an empty OAS specification containing a single component.| Allows publication of a RAML API fragment asset. | ||
| Overlays: A partial description of the API specification that you can use to overwrite non-functional aspects of the API specification by composing it with the original specification, for example, translating the documentation to other languages. | RAML overlay | Can be simulated with JSON patch or merge preprocessing. | Modified APIs can be published as an API asset. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Overlays: A partial description of the API specification that you can use to overwrite non-functional aspects of the API specification by composing it with the original specification, for example, translating the documentation to other languages. | RAML overlay | Can be simulated with JSON patch or merge preprocessing. | Modified APIs can be published as an API asset. | |
| Overlays: A partial description of the API specification that you can use to overwrite non-functional aspects of the API specification by composing it with the original specification, for example, translating the documentation to other languages. | RAML overlay | Can be simulated with JSON patch or merge preprocessing. | Allows publishing modified APIs as an API asset. |
| Libraries: The unit containing collections of related reusable description elements. | RAML library | Can be implemented using an empty OAS specification containing multiple components. | Allows publication of a RAML API fragment asset. | ||
| Fragments: Stand-alone component of the specification that describes a specific element. | RAML fragment | Can be implemented using an empty OAS specification containing a single component.| Allows publication of a RAML API fragment asset. | ||
| Overlays: A partial description of the API specification that you can use to overwrite non-functional aspects of the API specification by composing it with the original specification, for example, translating the documentation to other languages. | RAML overlay | Can be simulated with JSON patch or merge preprocessing. | Modified APIs can be published as an API asset. | ||
| Extensions: A partial description of the API spec that can be used to overwrite non-functional aspects of the API spec composing it with the original specification, like for example adding the security information for a managed API | RAML extension | Can be simulated with JSON patch or merge preprocessing. | Modified APIs can be published as an API asset. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto as the previous entry.
No description provided.