Lab 3: Publish the Omni Channel API to Exchange
In Lab 1 we examined how to use Anypoint Exchange to facilitate the API discovery process. In Lab 2 we learned how to use Anypoint Design Center to design the specifications for a modern RESTful API. In this lab we will learn how to publish our API to Anypoint Exchange so that API consumers and API developers within the organization are able to leverage the API through "self-service".
One of the biggest challenges encountered by early adopters of SOA was how to scale their development activities. SOA maintains many of the reuse principles that we have discussed in our "API-led" approach to software development. Unfortunately, most SOA efforts could not achieve their reusability objectives because of a few limiting factors including:
Poorly documented services
Lack of mature tools to facilitate service discovery
Over-reliance on limited number of knowledgable resources
Burdensome processes for gaining access to services
As a result, many SOA-based initiatives were only able to partially achieve their reusability objectives because developers would adopt the path of least resistance and simply recreate services rather than reuse them. The MuleSoft Anypoint Platform addresses all of these issues by providing innovative tools like Anypoint Exchange that alleviate these challenges.
Let’s take a look at the process for publishing and documenting our reusable Omni Channel Experience API.
Before we get started, make sure you are logged into the Anypoint Platform and viewing the Anypoint Design Center screen. You should have your "<username> - Omni Channel Experience API" open and visible. We have only defined a few resources and methods at this point and need to author the full API in order to complete the exercise. Rather than build it from scratch, we have the ability to import an API specification previously constructed for the workshop.
In a new browser tab, go to the Anypoint Platform and search Anypoint Exchange for the API named "Omni Channel Experience API".
Note: If you do not remember how to search Exchange then please refer back to Lab 1 of this module for detailed instructions. You may find multiple variations of the "Omni Channel Experience API" in Exchange with slightly different names. Just make sure you locate the one titled: "Omni Channel Experience API" with no initials or usernames appended to it.
Click the arrow on the "Download" button, and select
As RAML, to download the RAML API Specification.
Your downloaded API specification will be contained in a .ZIP file named "eapi_omnichannel_api-VERSION-raml.zip" (or something similar). Make note of where you saved the zip file.
Return to the browser tab containing Anypoint Design Center opened to your API. In the "Files" area of the Project Explorer, click on the "ellipsis" menu on the top line then select "import":
There are several ways to import an API specification. We will be importing a RAML file, so leave that option selected and then choose the API specification zip file we downloaded previously to import. This should import the RAML that completely defines our API into our specification.
Anypoint Design Center supports both RAML and Open API specification (OAS) languages when importing an API specification. OAS is a common format popularized by open-source Swagger tools.
Delete the RAML file user-omni-channel-experience-api.raml from your project explorer that we were previously editing. We no longer need that file since the API we just imported replaces that specification. Click the "ellipsis" menu next to your file and then click "delete":
Delete also the omni-channel-experience-api.raml file.
Select the new RAML file we imported. You should see the following complete API specification:
Note the extensive use of references to other assets published in Anypoint Exchange. This API designer is using the features of Anypoint Exchange to efficiently reuse common data types, traits, and other API fragments.
Make sure to re-enable the Mocking Service. We will need to test our API from the API Portal in Lab 4 so let’s turn it back on.
This fully formed API specification is ready to be published. Feel free to explore the API using the mocking service if desired.
Note: The full API specification designates that a client_id and client_secret are required to use the API properly. We have not secured our API yet and will cover that in a future module. If you are trying to test the API using the mocking service then you can enter any value for these parameters and it will still work properly.
Click on the "Publish to Exchange" icon
You will be presented with a popup window to capture the attributes that you want to publish to Exchange. Most of these fields will be pre-populated and the RAML will be verified to ensure that there are no errors.
Click the "Publish" button when done. We have now published our Omni Channel Experience API to Anypoint Exchange for other developers to discover and consume!
Each time you publish and API Specification you will generate two assets: * RAML Spec: This is the RAML Specification. Everybody on the organization can discover the spec and documentation. * Rest Connector: This is a connector automatically generated for the API you have just defined. We will cover this in more details on Module 2 and Module 9.
As demonstrated in Step 2, publishing your API to exchange is as easy as a few clicks. However, Exchange has really only just captured the basic attributes and documentation for your API at this point. Ensuring that your API is easy to find and "self-service ready" is your responsibility as an API designer. Let’s find our API in Exchange and add more to our API documentation.
Navigate to Exchange 2.0 from the icon at the top of Design Center.
Use the search bar to find your API if it is not readily visible in the list of Exchange assets. Click on your API once you find it:
Click on either of the "Edit" buttons to launch into edit mode.
Exchange assets are documented using "markdown" language. Markdown language is a format-agnostic syntax used for creating documentation independent of how it will be rendered (i.e. HTML, PDF, text, etc). It is used by popular applications like GitHub as the standard way to create software documentation. For more information on markdown please refer to:
Create your own documentation for your API, or copy the following text into the editor:
The **Omni Channel Experience API** is used to simplify access to Orders, Products, and the Shopping Cart features required for mobile and e-commerce applications. Developers requiring can easily compose innovative applications by leveraging this API to do the following: - Retrieve the Product Catalog and details about a product - Add products to a stateful shopping cart - Search for orders and retrieve their status - Create a new order
Note: if you prefer WYSIWYG editing then you can click on the "Visual" button at the top and be presented with a visual editor instead of the markdown-based editor. Both editors product markdown at the end.
Click on the "Save as Draft" button at bottom of screen. Drafts of your API documentation are not published until you formally "Publish" the final updates to Exchange, so feel free to save multiple drafts as you create your documentation.
Note: From there you can press publish or exit draft. By clicking the second one, nothing is published and can be edited all the time.
Exchange documentation can be comprised of multiple pages. So far we have just created the home page for our API.
It is common practice to include links to other content like video tutorials in our Exchange documentation. This makes it easier for the interested developer to gain access to all of the documentation required to learn how to use the API.
Congratulations! You have completed Lab 3.
Let’s learn how to create an API Portal in the next lab.
Please proceed to Lab 4