[This article was written by Paul Bruce.]
APIs permeate the connected world, used by technical and non-technical professionals alike. At some point, we all work with APIs, building them, selling them, maintaining them and consuming them. With so many viewpoints and opinions, misconceptions can quickly emerge, clouding the decision-making process and hindering execution of improvements to the business of API delivery.
This article focuses on dispelling some of the most common myths around the API lifecycle, so that you don’t fall at the mercy of misinformation in your own process. The points in this article are graciously lent by Ole Lensmar, CTO at SmartBear, based on his recent talk at AppsWorld North America on the topic.
Myth #11: APIs only solve a technical problem
APIs don’t have buttons and flashy graphics, but that doesn’t diminish their importance to non-developers. Business decision makers all need to know that APIs can speed time-to-delivery by compartmentalizing work projects, providing well-modeled data to business users through spreadsheets, and even act as their own product in the data economy.
If your organization has pigeon-holed APIs to be a geeky, technical asset solely existing for the benefit of the developer, you may find that simply sitting down with the right non-technical business owner, say the CTO or Director of IT, is just the kick start you need to break through this misconception. A 15-minute review of the non-technical reasons that APIs are a big deal to everyone in your organization might be just what the doctor ordered.
Myth #10: APIs are secondary to a business
Even if APIs are perceived as just “glue” for your organization, or if instead of shipping a public API you use them internally, integrations between systems are a vital part of the health and function of a business. Just ask the finance department to go without a few critical integrations that depend on APIs, and you’ll see how quickly business as usual will come grinding to a halt.
Similarly, many organizations use some form of traditional database scheme behind the scenes. You wouldn’t call the code and queries in the database “secondary” to the business, and so you shouldn’t when it comes to the APIs that connect the systems an organization uses. Every company is a tech company in the information age, and understanding the importance of the working components underlying your business model protects you from bad or uninformed decisions when it comes time to change.
Myth #9: Their API will always be available
Do you think that 3rd party API you just integrated with will be around forever? API companies, especially those who only produce APIs, can very quickly crumble unless they have a healthy ecosystem and leadership to back them.You must choose your 3rd party integrations wisely, because if they happen to fold, you may be in for quite the scramble to find another API provider that meets your technical needs and financial requirements.
And if you think you’re safe integrating with the big players such as Google APIs, Twitter, and Amazon – guess what? You’re not. While it’s not likely that they’ll experience a catastrophic collapse, these companies do change their public API schemas regularly. If you’re not paying attention, your integration with large providers might break due to these changes. It’s also important to consider that you hold far less authority as one of countless other API consumers to a popular API, so your vote on how these APIs change (if you even get a vote) may count far less than if you were to integrate with an API provider that really depends on your subscription to their services.
Myth #8: Our API can’t be hacked
Just because you haven’t been hacked yet, or you have taken what youbelieve are adequate measures to protect misuse of your API, rest assured your API will be the target of hacking attempts from malicious users and bad actors.
It happens all the time in the news – just consider the Moonpig breach and constant attacks on companies like Uber and Tinder, as a clear sign that public APIs constitute just as much of a security problem as any other web or mobile app. Certainly the folks at Uber thought about security before releasing their API publically, but through elbow grease and malicious intent, hackers still found a way to misuse their APIs. If you are publishing a public API, it’s important to bake in time to review your API for conformance to guidelines like the Top 10 OWASP scans for REST or SOAP web services. Or you can protect your API with tools like this.
Myth #7: Their API can’t be hacked
Each of the points above applies when you think about integrating with 3rd party APIs as well. If they don’t have a zero-day response policy, you may want to reconsider trusting your data with their web service. Also be wary of API providers that present compliance at a point in time, but aren’t willing to go into detail with you about their continuous security process. If they’re not constantly ensuring the conformance they tout, then they might not even know they’ve been breached.
Trust no one. Be vigilant. Demand the same from others.
Myth #6: SSL + OAuth is enough
Thorough security is never locked to one layer, so it’s important to have multiple layers of security considerations in place in order to deter hacking attempts and reduce single-point vulnerabilities. Relying too heavily on a single layer such as SSL as a transport security mechanism or OAuth as an authorization pattern, without considering network-level or data-level vulnerabilities, will make it very easy for hackers to play along with the few mechanisms you’ve established until they find an unprotected aspect of your system to exploit.
Just consider the bearer token exploit, in that without SSL the entire authentication process is bogus. There are other common vulnerabilities too, but the overarching theme is that your approach to securing your APIs must be multi-layered. Using OAuth + SSL might be a major step in the right direction, especially if you use something as arcane as Basic authentication, but it’s just one step. Make sure you take the next one soon as part of your deployment or maintenance plans.
Myth #5: Metadata is bad
Put simply, the idea that Metadata is bad is patently false. Metadata is just ‘other information’ than the primary data of purpose. Common programs such as Microsoft Office, for instance, produce lots of metadata; the primary data is the content that you include in your document or spreadsheet, whereas the metadata is author and origin information, credentials to underlying data sources, and other information that becomes associated with a document throughout its creation, but is usually not exposed within the document itself.
API metadata can be considered critical to the primary function of the API but this data is exposed in non-standard methods to the way that primary data is delivered. Metadata can exist in the form of custom headers to abate the process of baking new functionality into the existing HTTP body schema or specification. So long as everyone using the API understands why ‘metadata’ exists separate from traditional ‘data,’ all metadata is data. Use it wisely.
Myth #4: You need to adhere to REST principals
One of the most constraining business practices is to follow strict adherence to some form of guidelines even when they don’t make sense for a given situation. REST principles are great and all, but REST lacks pretty important things like a built-in formal schema definition and bolt-on standards for doing security (WS-Security, WS-Trust), distributed transactions, and asynchronous processing (JAX-WS).
Regardless of whether you have SOAP or REST services, you should be willing to consider the context by which you apply architectural principles. Using REST as a canon on how to build APIs misses the point of REST: build what is appropriate based on thoughtful consideration of the domain.
Myth #3: Top-down creation of APIs is only for elaborate architectures
Not so! APIs come in all shapes and sizes, especially in the enterprise. Rewriting small portions of infrastructure one at a time is often the only way teams can make headway in migrating from a monolithic web service approach to a more scalable, maintainable model like Microservices.
If you’re trying to partition a class of problems that are thematic throughout your infrastructure, then yes, a top-down approach is often a good thing to try…on the whiteboard…with the rest of your team. The most effective APIs are designed with the consumer in mind, which is great news for people who like to think about their designs before getting lost in implementation details. Even the smallest API should be well thought through, and taking a top-down approach to API design at each opportunity can help to improve the consumer experience and the overall landscape of your API infrastructure, one endpoint at a time.
Myth #2: Nobody uses SOAP
This could be one of the most prevalent API misconceptions that exist today, but it grossly misrepresents the current API economy. Plenty of organizations have existed well before the existence of REST APIs and have been through programming era after era. SOAP was the only option in the early SOA days, obtaining both mass adoption in the enterprise as well as years of ecosystem support and tooling. Now, of course, there is a shift away from SOAP for applications and devices that are designed to trade formality for agility. But much of our world is built on XML, no matter how hard we want to move on.
Most notably are organizations that employ a formal back-end, an enterprise service bus (ESB), where many ESB vendors have standardized on XML documents as a native structured input and output format. Building APIs that use SOAP naturally fits in to this kind of ecosystem, and makes sense for teams where the informalities of REST/JSON aren’t feasible due to compliance or regulatory concerns.
Myth #1: Our API works!
How do you know this? Do you have proof such as proper test coverage, both positive and negative condition checks in your tests, and are you monitoring your APIs to see exactly what the uptime percentage really is?
The fact is, most API development teams build and ship without proper testing or monitoring practices to ensure that the API being delivered does exactly what it’s supposed to do, reliably and safely. Maybe another project takes priority, the “quality analysis” problem is offloaded to another group, or the problems in production are a known quantity solved by a workaround.
The only way you don’t fall into the hazards of thinking your API works when it really doesn’t is to proactively test to prove that your API stands up to the challenge.