Why a “one-size-fits-all” approach to API development doesn’t work

There are multiple uses for and approaches in developing APIs. Which strategy works best depends on your staff, your target outcomes, and your ability to reuse the work you are creating.

Simplistically speaking, APIs can be broken into two broad types:

• First are those used for internal projects that target internal processes and integration with existing systems.
• Second are the APIs that you support for external audiences that are more published, product-type interfaces that you have to support for longer periods to a diverse set of audiences.

Evolving your API development

Taking a full lifecycle management approach to all APIs is probably overkill.

But you know you need to secure and operationalize new and existing APIs, so how do you decide whether to take a project or product type approach to API development? Here are some guidelines to get you started.

Project approach

Choose a project approach to API creation if:

You do not have a reliable, frequently updated repository for your APIs.

A recent report by Salt Security found 82% of organizations lack confidence in knowing API details such as exposed personally identifiable information (PII). These could include CPNI, PHI, cardholder data, and other sensitive information, and 22% of organizations admit they have no way to know which APIs expose PII.

An internal marketplace or catalog can help ensure that your APIs are reused and can be found, regardless of where they are created or hosted in your organization – allowing you to reduce time and cost for internal projects and put your APIs to good use.

Your API-based integration requires a level of customization and mapping to be functional.

This is where connector-based integration (iPaaS) can help reduce development and provide the customization needed.

You’re on the fence about cloud adoption

Perhaps you have a large amount of legacy infrastructure on-prem and few API-enabled customized apps, and you’re worried about API security in the cloud – cautiously hoping for a proven solution before jumping in with both feet.

On the other hand…

The problem with a project-based approach is that while it seems faster, in the long run it can actually slow you down.

In healthcare, for example, my colleague Ruby Raley points out that project-based integration won’t allow organizations to move at the speed they need to adapt to ongoing regulations and increasing pressure. Instead, she argues they should treat their APIs as a self-service platform for developers.

“Developers need to be able to get their security tokens and get their applications registered, then programmatically, without having to ask anyone, download and test them — and finally move to production via an API portal.”

Product approach

Choose a product approach to API creation if:

You are looking to provide a set of APIs that can be monetized (directly or indirectly) by your organization from third-party usage.

This usually requires supporting an external portal or platform and service level agreements: a central hub allows you to upgrade connections to key partners or applications using APIs.

Your business model depends on the expanded reuse of these APIs.

You have a team that continuously improves and expands on these “API Products.” When you future-enable all API assets through common onboarding and management, you have the flexibility to grow across multiple API patterns, from GraphQL to Streaming APIs.

You don’t want to tinker with API security. Instead of forcing developers to code security, protect your APIs through a defense-in-depth strategy, and use a gateway with prebuilt policy-based enforcement points to reduce vulnerability risks.

You can be both fast and secure

Finding and reusing APIs instead of recreating them for each project means you can speed the successful delivery of digital business initiatives – whether it’s improving the customer experience or modernizing your business.

Bundesagentur für Arbeit, the German federal employment agency, enables secure, seamless eGovernment services for 100,000 employers and millions of job seekers.

During the Covid-19 health crisis, BA had to distribute an additional 50 million EUR in benefits, pushed through emergency legislation. To help process a massive quantity of applications from citizens, they had to react fast.

Working with Axway, they compressed the equivalent of five years of work into three months. End-to-end security was paramount. Thanks to a single point of control for API security, BA’s dedicated cyber security teams defend the organization against up to five million cyber-attacks every day.

The French utility ENGIE, a global leader in innovative, low-carbon energy and services, built a Common Data Hub to detect APIs that were already in use internally and make them usable company-wide.

They realized multiple business units were paying for the same weather data, and by creating one standard weather API, each unit can now automatically pull the data from the same place without having to buy it a second time.

As a result, ENGIE now makes three times fewer requests to weather-data providers – saving money, and also giving teams a large amount of centralized data for research and analysis.

Success factors

The key success factors for both of these approaches, project or product, are that you:

• Engage the consumer of the APIs and determine their requirements first.
• Have a way of tracking API usage and determining what success looks like before you start.
• Have a central place where all APIs can be exposed and reused.
• You have made a strategic call on building the right things.

Axway can help. Our Amplify API Management platform helps you take either approach and centrally consolidate your API assets for better reuse – regardless of where they are deployed – with central governance for full control and visibility.

We also have a team of API experts that can help you make the right calls on your next steps.