Welcome Azure API Center
I was really looking forward to this new service because I strongly believe an API catalog is a critical tool for every enterprise that wants success with its API program. An API catalog brings together the different roles involved in an API program. By promoting collaboration between them, it fosters API reuse, ensured compliance, and better developer productivity.
The Azure API Center is the long-awaited API catalog we were missing. Creating an API inventory is pretty straightforward and intuitive. For a step-by-step procedure, you can check out the Microsoft docs.
In this first preview, there are two key features:
✅ API inventory
The API Center provides a comprehensive repository of available APIs within the organization, no matter where they are deployed or in which lifecycle stage they are. This allows your API developers and application developers to contribute to the API design, discover and leverage existing APIs, and promote consistency across projects.
✅ Define metadata properties
By adding metadata, you can extend the data model behind the APIs, Deployments, and Environments, in order to store the information to set up the governance model you have in mind. By adding your own metadata, you can facilitate clear and consistent communication between the API program managers and developers. This leads to better API design, adherence to best practices and as a result, an elevated overall API quality.
In the current version of API Center (preview), we can mainly interact with 3 objects: APIs (along with their versions), Deployments (the development stage of your APIs), and Environments (where the APIs are hosted). The pseudo-ER diagram below shows the kind of information every entity holds and their relationships.
While exploring the API Center, I had a few goals in mind:
- understand whether I can use this tool to manage API dependencies.
- understand how can I Integrate the API center in the API design workflow.
- understand how the different stakeholders can interact with the API Catalog.
Manage the API Dependencies
In today’s landscape, it has become increasingly common for applications to leverage multiple APIs to access diverse functionalities. To make the scenario even more complicated, each API comes with its own dependencies, both internal and external. To ensure smooth API adoption throughout an entire enterprise, it is crucial to establish a method for managing and tracking all these specificities.
Analyzing dependencies is key for both business and technical teams. Let’s take a practical example: risk management.
- By being aware of the dependencies, the API product owner can proactively mitigate risks by monitoring changes, having backup plans, or seeking alternatives when necessary.
- By being aware of the dependencies, the API architect can ensure backward compatibility, identify versioning strategies, and define the possible migration paths.
Let’s try to implement this use case. As the first step, I created 4 APIs as follows:
In order to identify dependencies and understand the impact of patching, it would be extremely useful to have a graph visualization where we can see the different objects (APIs, applications, databases, etc.), the relationship between objects (e.g. depends on, consumed by, etc.) and optionally add properties to those relationships.
When we leveraged the “Metadataschema” in the API Center:
- We created a “Dependencies” object with two fields: depends_on and motivation (would be better to have an array of objects to support multiple dependencies).
- We assigned the “Dependencies” object to the APIs category.
- We edited the 4 APIs I created before to define their dependencies (if any).
Now that we have the dependencies stored in the API Center, we need to build up some customization to visualize the relationships we defined. I can fetch the data using the API Center REST API and leverage Gremlin on CosmoDb to display a graph.
Every API becomes a VERTEX and properties are attached to the vertex.
The “Dependencies” object can be used to create the depends_on EDGES and the motivation field is added as EDGE property.
With some plumbing (sync between API center and CosmosDb), we are able to display the API dependency graph so the API team can click on a specific node subjected to change and get a visualization of the assets that are potentially impacted by that change. Awesome!
I strongly believe this is a key feature and it would be lovely to have something similar built-in the API Center, so that no additional plumbing and external db/visualizations are needed. #feature-request.
Integrate with the API design workflow
Irrespective of what your API design workflow looks like, the API Center should be the GOTO tool to manage the creation, evolution, security and compliance of your APIs.
- The API catalog should emphasize security by incorporating security standards and guidelines into the API development process. API program managers can define and enforce security policies, such as authentication and authorization mechanisms, data encryption, and more. Developers can leverage these predefined security measures, reducing the risk of vulnerabilities and protecting sensitive data
- The API catalog should play a vital role in ensuring compliance with industry regulations and standards. It allows API program managers to track and manage compliance requirements related to data privacy, governance, and industry-specific regulations. By aligning APIs with compliance standards, organizations can maintain trust and confidence among their users and partners.
Basically, every person and tool involved in the API design workflow should be able to push and pull information from the API center. For example, a new version of the API design could trigger the upload of the Open API document to the API Center. A missing compliancy flag could block the API rollout to the next environment, etc.
All the API Center operations are served by an underlying API that can be leveraged to automate those interactions. It would be lovely to have an integration with Azure Event Grid to implement a push mechanism when something changes in the API Center. #feature-request
Below is a possible API design workflow with some interactions with the API Center.
Stakeholders' experience
There are different roles and different responsibilities, so what kind of experience should the API Center offer to these different audiences? Will business and technical profiles operate the same way within the API Center? It’s hard to tell, but in the coming months, we will see what kind of features will be released and what the roadmap will look like. What’s for sure is that we are eager to get more!
As of today, there are no ad-hoc RBAC roles created for the API Center or role-based screens. Therefore, the same functionalities are available to every API role.
While the API Product Manager undoubtedly benefits the most from the API Center, it’s important to note that other stakeholders can also derive significant advantages from it. To try to put together roles, customer expectations and the features that will be surfaced by the API center, I created a simple visual that I will update in the coming months to keep track of the evolution of the service.
Conclusion
In conclusion, the API catalog serves as a valuable tool for organizations, enabling collaboration between API program managers and all the different roles involved in the API program. It promotes API reuse, improves API quality, ensures security and compliance, and eventually enhances developer productivity. By leveraging the capabilities of the API catalog, organizations can establish a strong foundation for successful API initiatives.
Subscribe to our RSS feed