Support for Multiple Responses Added in RAML 1.0 Import
|Release Date||Mar 13, 2020|
As part of our ongoing work on support for multiple responses, we have released some related changes in RAML
1.0 that may change how your imported API entity looks like.
Currently, our products (API Transformer, Docs and SDKs) support the following in terms of responses:
- A single success response definition (status code
200or any other in the range
- Multiple client/server error response definitions (status code range
400 - 599).
We now plan to support all valid status code ranges
5XX with complete information about response headers as well as allowed content-types and related response body schema definitions and examples. Though any work related to this is still in its early stages, we have released partial support for it in RAML
1.0 import. So if you are importing RAML
1.0 files in the Dashboard, you might notice some additional types loaded from the new response data for the following cases:
- Your RAML file contains response definitions with status codes in the range
3XXthat have inline schema definitions like below:
responses: 303: body: application/json: properties: redirection_message: string
- Your file contains multiple success response definitions with status codes in the range
200-208and the responses (excluding the first one) have inline schema definitions. Note that the first response definition was imported previously as well so any related types for that will appear as before. The only changes you will see are related to importing additional success responses with type definitions that were previously ignored e.g. in the example below an extra type will appear because of loading type information from response with status code
responses: 200: body: application/json: properties: message: string userId: int 206: body: application/json: properties: receivedContent: string
- Your file has error responses in the range
5XXwith either inline schema definitions or definitions referencing a global type/model which is referenced only by error responses across the API. The behavior for the latter case is affected because APIMatic loads such types as
Exceptiontype models but with this new generic support of responses, they will also be loaded as normal
Structuretype models that may be considered extra in the current context.
The additional types in above cases will not affect your existing/new generated docs/SDKs but will only appear in the editor. In case you want to disable this new data, you can upload a Metadata file along with your specification at the time of importing, with the
DisableMultipleResponses import setting enabled.
Have questions? Submit a request.