Posted on by Tom Smith

APIs = Access

To gather insights on the current and future state of API management, we asked IT professionals from 18 companies to share their thoughts. We asked them, "How does your company use APIs?" Here's what they told us:

Data Access

  • More data sources are being accessed through APIs. Communicating with APIs for reading and writing data back to those systems. At the core how we develop applications, manage DevOps and communicate with source systems.
  • APIs are quickly becoming the de facto way organizations deliver value in a digital world. Companies create discrete applications and data sets and expose them as a series of API-enabled services. The customer experience is then highly dependent on the strength of the underlying API architecture. We’ve seen this trend before. Web apps exploded in the early 2000s and then mobile apps earlier this decade. Now, APIs are following suit.

    The organizations that master this wave of API development, and deliver compelling experiences via those APIs, will drive a decade of competitive advantage. And as with all new emerging trends, the key to success is part people and process — hiring for API skills and adopting an API-first development practice — and part technology that provides a secure, fast, and scalable API infrastructure.
  • APIs provide access to data, software, and applications to enable the business to run and applications to provide a better user experience and customer experience. 
  • Our platform is a publisher of hundreds of business banking API endpoints as well as a heavy consumer of other industry and utility APIs ourselves. It’s safe to say that without APIs there would be no platform. We’re in the business of connecting businesses and corporate clients with banks, which is only possible over rich API data exchange. The problem is — every bank today has its own way of offering services to clients, so we had to create that layer to enables the delivery of services to many, in many ways.

    In our case — connecting any business application to any bank without the hustle of re-implementing the whole product for every bank and client combination. The current state for many is a file-based exchange with banks over a variety of protocols and formats, which in most cases means a custom project for each client to establish a connection between their ERP and bank services or data. 
  • We use APIs to request permissioned data and perform transactional capabilities. 
  • As the Data-as-a-Service company, we use APIs in two directions: first, for obtaining data from vendors such as Google and Amazon, and second — supplying it to our customers, who, for the most part, represent the Marketing Technology industry.

Internal and External Development

  • Primarily mobile development and quite a bit of web. There would be no apps or websites without APIs. Integration is a big issue.
  • We have a cloud-based integration platform that makes extensive use of APIs. Integration historically started with files, then moved to databases and service buses and now rely heavily on APIs. Many modern software applications provide a set of published REST APIs. These provide the perfect integration point as they provide both the transport (HTTPS) and data format (JSON), while the past with files, integration required two distinct sets of technology, a file transport, and a file format. Since many modern software applications publish their APIs, we have built connectors to these applications. The connectors encapsulate the API definition into an easy-to-use package on our integration platform.

    A user wishing to build an integration can select two connectors (for example Salesforce and Microsoft Dynamics Finance and Operations) and easily map customer information from Salesforce to Dynamics Finance. For users wishing to connect to APIs that we do not have a connector available, they can set up their own definitions and have our integration platform connect to any API. In addition to these API consumer use cases, we also have API provider capability in our integration platform. This allows a user to define a set of APIs on our platform (for example, to check order status) that they can then make public.

    This published API could then be connected to a backend system such as an ERP system. When a customer used the public-facing API published on our integration platform, the API could be connected to the backend ERP including translation and security to provide an update on their order.
  • We generally don't use the provided kits by the main providers but rather an HTTP library available in our programming language. For us, it's "requests" in Python. We then read the API documentation for each service and implement the calls needed to make it work. We have developed internal libraries to handle our main usage for our frequent library, which includes Stripe, Mailgun, and Intercom.
  • All the products and services we provide can be accessed via APIs. While we understand the value of web applications to convey meaning in a visual way or to engage with a broad audience, it is in our DNA to first and foremost engage with developers — and we do that by providing them with carefully built and documented APIs to interface their own products with ours. 
  • APIs power every piece of our product ecosystem. We have internal APIs that our web and desktop applications use, as well as public-facing APIs that our customers use to automate and customize their workflows. Beyond our own APIs, we integrate against a number of third-party APIs — from version control systems like GitHub to API gateways like Axway. 
  • We use APIs in two high-level categories: Internal and public APIs for our product offering and front-end applications are backed by a powerful set of APIs. We follow a three-layer API design pattern, including 1) Experience APIs used by our front end to give the experience to our customers. 2) Process APIs where our processing and business logic resides. 3) Systems APIs that use our datastores to access the data.  API for our internal IT projects to integrate the systems we use. For internal IT projects, we use the same design pattern as above. However, for these projects, we build the pattern using our own integration and our API manager product, both of which are part of our platform.

Microservices

  • In the last 10 years, APIs have become the universal language to integrate applications.  Monolithic applications kill innovation, it's too slow to integrate new things via the ESB. It's important to have: 1) distributed integration; 2) container-friendly solutions; and, 3) APIs are key to integration. Customers are moving away from choosing point solutions to solve one problem at a time looking for full-service pre-integrated solutions that work. 
  • Enterprises have built monolithic applications with a lot of APIs in one binary. When microservices come along, these are cut into small pieces. Instead of 50 APIs, you will have five. With serverless, it's an API call and then running a piece of code. One API code to call one function. Find the smallest unit of compute shared across monolithic, microservices, and serverless – that’s the APIs. 
  • There are two broad ways: we build (and share and consume) differentiating APIs related to our core business, and for everything non-core, we prefer API-first SaaS vendors. In our domain, we maintain an ecosystem of almost 500 microservices that comprise our mass customization platform. These microservices are used by our portfolio businesses — and third-parties fulfilling orders on our behalf – for everything from artwork preparation to shop-floor optimization to shipping rate calculations.

    We’re big believers in providing composable building blocks that our businesses can use to solve problems in novel ways, and we look for the same discipline when buying solutions outside of our domain.  Traditional vendors with monolithic solutions expect you to conform to their platform; API-first vendors allow you to integrate their functionality into yours.

Other

  • Support different types of file services. We use them to manage the content lifecycle, write from ingest to inter archiving, data governance, and so forth. Every platform has to expose APIs to build custom applications and integrations. Within the platform itself, there are many services that use APIs.

Here's who shared their insights: