Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Treating All APIs Like They Are Public

DZone's Guide to

Treating All APIs Like They Are Public

When it comes to APIs, they're all hackable, so treating them that way will make sure you keep both your public and private APIs safe, performant, and reliable.

· Integration Zone ·
Free Resource

The new Gartner Critical Capabilities report explains how APIs and microservices enable digital leaders to deliver better B2B, open banking and mobile projects.

I was talking with the Internal Revenue Service (IRS) about their internal API strategy the week before Christmas, sharing my thoughts on the strategy that they were pitching internally when it comes to the next phase of their API journey. One topic that kept coming up is the firm line of separate between public and private APIs, which you kind of get at an organization like the IRS. It isn’t really the type of organization you want to be vague about this line, making sure everyone understands where an API should be consumed, and where it should not be consumed.

Even with that reality, I still made the suggestion that they should be treating ALL APIs like they are public. I clarified by saying you shouldn’t be getting rid of the hard line dictating whether or not an API is internal or external, but if you treat them all like they are public, and act like they are all under threat, you will be better off for it. This peaked their interest, was something they did not expect to hear from me and was something they would be adding to their recommendations for the next version of their API strategy.

The first benefit of treating your internal APIs like they are public is when it comes to security, logging, and overall API management. You have the tools in place to catch any threats and develop awareness regarding how an API is being used, both good and bad. While the threats might be minimized internally, developing the same awareness, and having the tools to identify who is using what and respond accordingly will benefit operations. API security isn’t just about firewalls, it is about an awareness of who is using what.

The next benefit is about the future of your APIs. If you treat APIs like they are public, and you ever want to make it public, you will be in much better shape. You will have proper authentication, management, logging, and security controls already in place. You can cross the line between internal and external with much less friction. When you are ready to work with partners on a project, the time to make resources available can be significantly reduced, making things more efficient and agile when it comes to working with partners.

I get the hard line between internal and external. However, I don’t get having two separate API strategies. Have one strategy. Treat everything like they are public, but then be very strict, and explicit about who has access to an API, and monitor, audit, analyze, and report on who has access to API resources in real time. These are web APIs. Let’s treat them all the same, and expect that there will be threats and misuse of varying degrees. Let’s treat all APIs equal, and reduce the chance people will become complacent with API management and security just because it is an “internal” API.

The new Gartner Critical Capabilities for Full Lifecycle API Management report shows how CA Technologies helps digital leaders with their B2B, open banking, and mobile initiatives. Get your copy from CA Technologies.

Topics:
api ,api management policies ,integration ,api security

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}