Skip to main content

Support for Multiple Responses Added in RAML 1.0 Import

· 3 min read

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.

Details

Currently, our products (API Transformer, Docs and SDKs) support the following in terms of responses:

  • A single success response definition (status code 200 or any other in the range 200-208).
  • Multiple client/server error response definitions (status code range 400 - 599).

We now plan to support all valid status code ranges 1XX, 2XX, 3XX, 4XX, or 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 1XX or 3XX that 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-208 and 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 206:
  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 4XX or 5XX with 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 Exception type models but with this new generic support of responses, they will also be loaded as normal Structure type 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.