API Development in Studio
Ensure that your Mule applications always refer to a single source of truth for your API specifications. Design, publish, and implement your API specifications with the following workflow:
-
Design an API specification.
You can either create and publish an API specification with the Visual Editor or with the Text Editor.
-
Publish your API specification to Exchange.
Make your newly designed API available to your entire organization as an Exchange dependency. As you change your API, you can publish new versions of your API specifications to Exchange. See best practices for API versioning.
-
Import and implement the API specification from Exchange to Studio.
You can either import and implement an API specification from Exchange or from Maven. Studio imports your API specification as a dependency. This means that your Mule application project now references the specific API version that you’re implementing. Studio checks your API and notifies you when there’s a new version available.
This workflow applies to AsyncAPI, OAS, and RAML API specifications. AsyncAPI specifications require Studio 7.18.0 or later, and Mule runtime engine 4.5.0 or later. OAS and RAML API specifications require Studio 7.8.x or later, and Mule runtime engine 4.1.4 or later.
With Studio 7.18 and later, you can import an AsyncAPI specification from Exchange and implement it in your Mule project.
API Specifications as Exchange Dependencies
Manage APIs for your Mule application the same way you manage the modules that compose your application. By leveraging Exchange as your unified repository for all your Mule application dependencies, you can check the latest versions of your dependencies, ensuring that your application is up-to-date with the latest API requirements.
Because the implementation of your API can change with each iteration, you must keep track so that you can update your Mule application to match newer specifications. To help you track these changes, treat your API specifications as dependencies of your project. This way, every time the specification design changes, the API publishes a new API version that you can manage from Studio. You can also update your application to match the new API version.
Each API version that you import from Exchange is stored as a reference to the API version dependency in Exchange, rather than as a local copy in your project’s structure. By referencing the API version in Exchange, Studio can periodically check the status of the version and notify you when a new version is available.
Scaffold AsyncAPI, RAML, and OAS API Specifications
Design your API using AsyncAPI, OAS, or RAML specifications in Anypoint Design Center:
| You can design an AsyncAPI API in Design Center with the Text Editor. |
When you import these specifications as dependencies of your flows, you can automatically generate (scaffold) the flows in your canvas based on the endpoints described in the API specification.
Studio leverages APIkit to scaffold the flow and make it easier for you to start developing a Mule application from an API specification.
| Studio doesn’t currently support scaffolding API specs that reference OAS, JSON schema, or AsyncAPI fragments imported from Exchange as project dependencies. To scaffold a spec with these fragments, you must provide the fragments inline within the spec or through fragment files that you create manually within your project directory. This limitation doesn’t affect RAML fragments from Exchange, which are fully supported. |
API Specifications as Local Copies in Your Projects
Import a RAML API specification either from your hard drive or directly from MuleSoft VCS into the /src/main/api/ directory in the structure of your project. This process creates a local copy of the API in your project’s structure. The imported API works as a standalone attachment to your project, meaning that every additional upgrade requires a manual import.
When the API imported as a local copy into your project’s structure is updated outside your Studio environment, reimport the API into your project. Studio regenerates all the flows based on the updated specification.
| Duplicated copies of your specifications can be created on your local drive. You can only keep RAML API specifications as local copies within your project’s structure. |
API Specifications as API Specification Projects in Studio
To start an API specification project in Studio and sync it with MuleSoft VCS, see Create an API Specification Project in Studio. Studio uses version control system (VCS) capabilities to keep your API specifications synchronized between your Studio workspace and MuleSoft VCS.
Import an API specification from MuleSoft VCS as an API specification project with VCS-enabled capabilities to edit your API specification using Studio and sync your changes with MuleSoft VCS:
-
Design an API specification in Design Center.
You can either create and publish an API specification with the Visual Editor or with the Text Editor.
-
Import the API specification from Anypoint Platform through MuleSoft VCS into Studio.
You can import the API specification as an editable asset by Synchronizing an API Specifications with MuleSoft VCS.
You can also edit an API specification that you imported as an API dependency in your project:
-
Import the API specification from Exchange to Studio.
Studio imports your API specification as a dependency. This means that your Mule application project now references the specific API version that you’re implementing. Studio monitors your API and notifies you when there’s a new version available.
-
Select the API specification imported in your project and Edit your API specification from Studio to later sync your changes to MuleSoft VCS.
| Studio uses the EGit plugin to edit API specifications offline. Studio doesn’t support the EGit plugin for Mule application projects tracked with your own VCS. |