Contact Free trial Login

Using Published RAML API Specifications in Studio 6.x and Mule Runtime 3.x

As described in Modify Published RAML API Specifications to Conform Completely to RAML 0.8 or 1.0, the code editor in Design Center is now (as of January 10, 2019) more precise in ensuring that the RAML in your API specifications is valid. Although RAML API specifications that you have already published might contain invalid RAML, you will have a long grace period in which to make corrections.

The information below explains how Anypoint Studio 6.x and Mule Runtime 3.x interact with RAML API specifications that are published both during and after the grace period.

Scenarios involving Anypoint Studio 6.x and Mule Runtime 3.x

  • Both during and after the grace period, in the majority of cases, a valid RAML API specification that is published to Exchange from the code editor will not be flagged with additional RAML errors when opened in Studio 6. Moreover, the implementation that is created in Studio 6 will be able to run without errors in Mule Runtime 3.

  • During the grace period, it is possible in some cases to publish to Exchange an API specification that still has invalid RAML according to the code editor, yet open the specification in Studio 6 and see no invalid RAML flagged. In such cases, there is in fact invalid RAML in the specification, but Studio 6 is not flagging it. Also, the implementation that is created in Studio 6 will be able to run without errors in Mule Runtime 3.

    After the grace period, it will not be possible to publish RAML API specifications that contain invalid RAML. Therefore, the situation described in the preceding paragraph will not arise.

  • In a very small number of cases both during and after the grace period, a valid RAML API specification that is published to Exchange from the code editor will be flagged with additional RAML errors when opened in Studio 6. In such cases, it will not be possible to create an implementation of the API specification and then run the implementation in Mule Runtime 3. If you experience this problem, contact MuleSoft Technical Support.

Scenarios involving Mule Runtime 3.x

  • Both during and after the grace period, in the majority of cases, a valid RAML API specification that is published to Exchange can deployed as an API proxy in Mule Runtime 3.

  • During the grace period, it is possible in some cases to publish to Exchange an API specification that still has invalid RAML according to the code editor. In that situation, you can still deploy the API specification as an API proxy in Mule Runtime 3.

  • In a very small number of cases both during and after the grace period, a valid RAML API specification that is published to Exchange from the code editor will not be deployable as an API proxy in Mule Runtime 3. If you experience this problem, contact MuleSoft Technical Support.