What happens when the required integration is with a noncommercial third-party API or is an industry-specific platform that isn’t wired into IFTTT platforms? Or what if more complex integrations, workflow orchestrations, data manipulations, or data volumes make using IFTTT platforms less attractive?
Development teams might consider test-driven development (TDD) methodologies to validate and prototype with APIs. This approach asks development teams to construct unit tests and higher levels of orchestrated, automated, and continuous testing before using the API’s capabilities directly in composite services or applications.
TDD is a powerful approach when developing APIs and microservices because it defines and documents the expected uses and boundary cases. Test automation helps flag any changes to the service that might create downstream impacts.
The approach works equally well when consuming third-party APIs. Developers can use tools like Postman to import API specifications, understand the API, build test suites, and then integrate the tests into continuous integration/continuous delivery (CI/CD) pipelines and other devops tools. Other tools to review include Katalon, RapidAPI, Parasoft, and SmartBear ReadyAPI.
These tests not only help validate the APIs, but developers can also use them later for automated and continuous testing. In production, they can help validate if and when third-party API changes break tests and require review and fixes of any services and applications using them.
Use low-code integration platforms to build reusable gateways
What happens if you plan to integrate with multiple platforms, and the integrations need to be reusable in numerous services and applications? Maybe your organisation is customising employee onboarding applications, marketing tools, and field operations workflows that require integrating with HubSpot, Workday, SAP, or other platforms.
I spoke to Ed Macosky, head of products at Boomi, about the opportunities in trying to share data and enable workflow and collaborations with everyone in medium and large organisations. These organisations need more than validating APIs; they require a scalable integration process.
He expresses the challenge this way: “How can developers solve this end-to-end picture of connecting everyone to everything, like connecting all the data sources, understanding all the data within an organisation, integrating that data, developing services, creating user-driven workflows, and exposing it to front-end applications that engage users?”
Integration platforms such as Boomi come with connectors to common SaaS and enterprise platforms along with low-code tools to enable rapid development, testing, and deployment. Instead of creating point-to-point integrations, one integration can serve multiple downstream applications and composite services.
Other integration platforms include Jitterbit, MuleSoft, PMG, and SnapLogic. Application integration or Integration Platform as a Service (iPaaS) platforms differentiate on a wide range of capabilities, including ease of use, data management features, operational functions, and self-service options.
Using an integration platform is highly strategic for organisations that want to tailor experiences to different business needs and departmental workflows. For example, the onboarding application can be customised to only show basic steps for someone joining an operation in a specific role, whereas it may allow new technical hires to select equipment or sales reps to set travel preferences.
What’s important for developers to remember is that validating an API is just the first step in the integration journey. Developers must then create reusable, scalable, robust, and supportable integrations.
Doing this well requires plugging integrations into an operating environment designed to support integrations with the expected business service-level objectives. Integration and iPaaS platforms offer these options and can be highly beneficial to organisations looking to make integrations a core development and operational competency.