API ChannelAPI DesignerAPI DeveloperAPI ManagementAPI MaturityDeveloper EvangelistDevOpsDomain-Based Information ModelMobile APIs

Will Developers Love Your APIs?

As Scott Regan of Apigee points out in this blog post, it’s important to do a variety of things that make it more likely developers will like your APIs and want to use them. You must go beyond just hosting a hackathon, to providing clear and compelling information, likely via a developer portal like these from MasterCard or GM. Other tricks of the trade likely include:

  • An API Catalog arranged in some functional organization that makes sense to the way developers (and business stakeholders) think about the domain.
  • For each API, information about the resources they manage, the methods each resource supports (GET, POST, etc.), the details of the interface (even when those are also discoverable), the model or schema of the data for method parameters or request/response messages, and a sandbox for trying out the API interactively to see how it works (see example, below).
  • Developer portals may also include downloadable SDKs that provide a native-language client for the API, as well as code examples for common use cases, and even a community site for developers who consume the API to trade tricks and tips with one another.


At digitalML we aim to make as many as possible of these artifacts easy and quick to generate and keep up to date. But the unique value we add relative to other tools is in enabling you to drive API design from a model of your business, in the form of Domain-Based Information Models coupled with reusable mappings, together with imported definitions of your business capabilities. This provides the basis to generate much of what you need for your developer portal, optionally organized by business capabilities to make APIs easier to browse.

Just as you seek to empower your customers via your API offerings, we deliver these capabilities through a combination of out-of-the-box product features and our own APIs, which you can use to extend these features in ways that are specific to your firm and your business context. So for example:

  • Send artifacts we generate such as WSDL, XSD, WADL, JSONs, and Swagger, and push them into your developer portal, out of the box. Swagger output can be used to automatically create a sandbox representation of your service, even before the team has built it.
  • Use our APIs to pull out these artifacts, along with additional metadata (NFRs, SLAs, etc.) to populate additional custom areas of your developer portal.
  • Use our APIs to pull out API or Service metadata that you want to push into your ignite runtime, and/or other parts of your runtime environment, such as API Management tools, ESBs, registry/repositories, or service management infrastructure.
  • Use your APIs to pull information from your multiple runtime environments about service levels, volumes, and other metrics, loading them in ignite. Compare these with non-functional requirements you’ve defined for your APIs and Services, to inform your design strategy as you refactor or extend services.

Whether you use ignite or not, consider an approach like this to integrate your end-to-end API and service lifecycle in a way that helps developers to love your APIs!


Related Articles

Check Also