salesforce Dreamforce On-Demand
Contact Us 1-800-596-4880
  1. Homepage
  2. Studio (7.x)

  3. API Development in Studio

API Development in Studio

To ensure that your Mule applications always refer to a single source of truth for your API specifications, MuleSoft introduces a workflow to design, publish, and implement your API specifications.

  1. Design an API specification.
    You can either create and publish an API specification with the Visual Editor or with the Code Editor.

    You can also create an API specification project in Studio and sync it with Design Center.

  2. Publish that 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.

  3. Import the API specification from Exchange to Studio.
    You can either import an API specification from Exchange or from Maven. Studio imports your API specification as a dependency. This means that your Mule application project now holds a reference to the specific API version that you’re implementing. Studio monitors your API and notifies you when there is a new version available.

You can use this workflow for OAS 2.0 and 3.0 and RAML specifications. It requires Studio 7.8.x or later, and Mule runtime engine 4.1.4 or later.

API Specifications as Exchange Dependencies

You can manage APIs for your Mule application as you manage the modules that compose your application. By leveraging Exchange as your unified repository for all your Mule application dependencies, you can monitor the latest versions of your dependencies. This ensures 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 isn’t stored as a local copy on your project’s structure, but as a reference to the API version dependency in Exchange. By referencing the API version in Exchange, Studio can periodically check the status of the version and alert you when a new version is available.

Scaffold RAML and OAS Specifications

You can design your API using either RAML or OAS 2.0 and 3.0 specifications in Anypoint Design Center. When you import these specifications as dependencies of your flows, you can automatically generate the flows (scaffold) 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 does not support scaffolding API specs that reference OAS or JSON schema fragments imported from Exchange as project dependencies. Instead, you can scaffold a spec with these fragments by providing the fragments inline within the spec or through fragment files that you create manually within your project directory. RAML fragments from Exchange aren’t affected by this limitation.

API Specifications as Local Copies in Your Projects

You can still import a RAML API specification either from your hard drive or directly from Design Center 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 and the imported API works as a standalone attachment to your project, meaning that every subsequent upgrade requires a manual import.

Whenever the API that you import as a local copy into your project’s structure is updated outside your Studio environment, you must reimport the API into your project and regenerate all the flows based on the updated specification, risking creating duplicated copies of your specification.

You can only keep RAML API specifications as local copies within your project’s structure.

API Specifications as API Specification Projects in Studio

You can start an API specification project in Studio and sync it with Design Center. Studio uses version control system (VCS) capabilities to keep your API specifications synchronized between your Studio workspace and Design Center.

You can also import an API specification from Design Center as an API specification project with VCS-enabled capabilities to edit your API specification using Studio and sync your changes with Design Center:

  1. Design an API specification in Design Center.
    You can either create and publish an API specification with the Visual Editor or with the Code Editor.

  2. Import the API specification from Design Center into Studio.
    You can import the API specification as an editable asset by Synchronizing an API Specifications with Design Center.

You can also edit an API specification that you imported as an API dependency in your project:

  1. Import the API specification from Exchange to Studio.
    Your API specification is imported to Anypoint Studio as a dependency. This means that your Mule application project now holds a reference to the specific API version that you’re implementing. Studio monitors your API and notifies you when there is a new version available.

  2. Select the API specification imported in your project and Edit your API specification from Studio to later sync your changes to Design Center.

Studio uses the EGit plugin only for the VCS feature of editing API specifications offline. Studio does not support the EGit plugin for Mule application projects that you might track using your own VCS.