APIs
Kyndryl Developer Experience (KDE) has a centralized location to discover, manage and run all APIs required to perform all the activities necessary for a developer’s job. This will allow developers to collaborate on API development, share feedback, and contribute to API documentation. In this centralized location for KDE APIs, developers can easily onboard, view, and invoke new APIs. They also have complete visibility of the API repository, API owner, any tech docs associated with the repo/API, OpenAPI specifications and access the API documents available on Swagger. Alternatively, API owners can manage API versions and track changes from one single place.
KDE service APIs are displayed based on the role levels established by the KDE role and the teams that have been assigned to.
APIs can be searched using filtering and advanced search options based on various criteria, such as versions, teams, applications, components, created date, modified date, or tags. If the relevant API is not available, the following message will be displayed: "Sorry, there are no docs matching the selected criteria"
A swagger button is available for each row that will redirect you to the swagger page in a new tab and display the APIs relevant to the developer's team or associated teams.
In KDE APIs swagger page, you can find the following information:
- API name (Title)
- API description
- API type
- API owner
- Tags
- Associated component
- Lifecycle: Development/ Alpha/ Beta/ In Production/ Deprecated/ Retired
From the KDE APIs page, you can perform the following actions:
- Invoke / run: Run the API as expected.
- View: View the list of APIs available for each user. This list will change depending on the user’s rights and areas of expertise.
- Edit: Based on the permissions granted, users can edit APIs accordingly. However, if users have edit permissions in GitHub repository, they can still update the API from the code on GitHub.
If you click the API menu on the left, it should redirect you to a page for Kyndryl's REST APIs. To add a new API, go to the Component Inventory page and use the Onboard New Component option.
API synchronization
KDE now enables automatic synchronization of API definitions from Swagger URLs instead of only relying on static YAML files. This ensures that KDE’s API Explorer and the VS Code custom extension reflect the most up-to-date API specifications when accessing Swagger without authentication.
For squads that maintain a Swagger file but require authorization, users can still view Swagger but will not be able to execute it.
Benefits:
Real-time accuracy
- When connected to Swagger hosted without authentication, the develop console retrieves the latest API specifications, ensuring developers work with the most up-to-date endpoints, parameters, and response schemas.
- Reduces the risk of outdated API documentation, a common issue with static YAML files.
Automated synchronization
- Eliminates the need for manual updates and version control of static files.
- Ensures all team members have access to the latest API specifications without additional effort.
Environment-specific configurations
- Dynamically adjusts API documentation based on environment settings (for example staging versus production base URLs).
- Reflects authentication-based access restrictions without requiring multiple YAML file versions.
API visualization in KDE
The API visualization graph provides a clear and structured way for developers to understand API dependencies and relationships within KDE. By introducing a dedicated API graph, users can better visualize how APIs are consumed and exposed, improving discoverability and usability.
The API visualization graph is integrated into the API Explorer (detailed view) and into the Component API tab. The default display is left to right for clarity.
API relationship and labels
Label | Description |
|---|---|
Owner Of | Points from the owner to the components they manage. |
Owned By | Points from a component back to the accountable owner. |
ProvidesApi | Links a component that exposes an API. |
ProvidedBy | Points from an API back to the component exposing it. |
ConsumesApi | Points from a component to the API it depends on. |
apiConsumedBy | Points from an API back to the components using it. |
dependsOn | Shows what an entity needs. |
dependencyOf | Shows what depends on an entity. |
parentOf / childOf | Represents hierarchical relationships between components. |
memberOf / hasMember | Defines group memberships. |
PartOf / hasPart | Represents sub-component relationships. |
Icon representation
Name | Icon |
|---|---|
Teams/Groups: Represents different development teams. |  |
System (Environment): Indicates environment-related components. |  |
API: Highlights APIs within the system. |  |
Component: Represents backend and microservices. |  |
Resources: Displays additional components relevant to APIs. |  |
Domain: Represents logical groupings of related services and APIs. |  |