WHAT IS AN API?

API is the acronym for Application Programming Interface, which is a software intermediary that allows two applications to talk to each other. Each time you use an app like Facebook, send an instant message, or check the weather on your phone, you’re using an API.

An application programming interface is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software. A document or standard that describes how to build such a connection or interface is called an API specification

What Is an Example of an API?

When you use an application on your mobile phone, the application connects to the Internet and sends data to a server. The server then retrieves that data, interprets it, performs the necessary actions and sends it back to your phone. The application then interprets that data and presents you with the information you wanted in a readable way. This is what an API is – all of this happens via API.

To explain this better, let us take a familiar example.

Imagine you’re sitting at a table in a restaurant with a menu of choices to order from. The kitchen is the part of the “system” that will prepare your order. What is missing is the critical link to communicate your order to the kitchen and deliver your food back to your table. That’s where the waiter or API comes in. The waiter is the messenger – or API – that takes your request or order and tells the kitchen – the system – what to do. Then the waiter delivers the response back to you; in this case, it is the food.

Here is a real-life API example. You may be familiar with the process of searching flights online. Just like the restaurant, you have a variety of options to choose from, including different cities, departure and return dates, and more. Let us imagine that you’re booking you are flight on an airline website. You choose a departure city and date, a return city and date, cabin class, as well as other variables. In order to book your flight, you interact with the airline’s website to access their database and see if any seats are available on those dates and what the costs might be.

How does an API actually work?

APIs unlock a door to software (or web-based data), in a way that is controlled and safe for the program. Code can then be entered that sends requests to the receiving software, and data can be returned.

A clear example of this in action is the Google Maps API. Users first have to sign up to receive an API key – once they have this the website can retrieve information from Google Maps.

There is a predefined list of requests that the user can enter. In the Google Maps example below, the origin is listed to the left, and is entered in the URL to the right. Once this is entered on a web page (or entered into the web browser), Google can process the request, and return the desired values – in this case, driving directions from Vancouver to San Francisco.

There is hardly an IT application nowadays that doesn’t provide an API that would specify how this application should interact with the rest of IT ecosystem. So, it’s no wonder that IT staff even at large enterprises increasingly use APIs to integrate multiple systems with each other, usually new ones with the existing IT estate.

At the same time, there are APIs and then there are APIs. Some of them make integration a breeze while others turn it into a nightmare for integration specialists.

As integration experts, we deal with all kinds of APIs – excellent ones, good ones, not so good ones and just plain awful APIs. That is why we’ve decided to share with software providers a few guidelines about how an API should look to be a perfect fit for integration projects (and therefore, make your product popular with developers and end customers).

Using APIs for Integrating Cloud, IoT, and Mobile

Most software and mobile applications nowadays have APIs, some of them to allow you to easily find the best restaurant in a new town, some of them to feed company’s logistics software with the latest information about the current location of goods. APIs are widely used both in B2C and B2B scenarios.

Even more than that, enterprise systems increasingly start supporting APIs as enterprise IT infrastructure is getting more and more interconnected. In the business world, APIs have become the driving force behind continuous and automated data exchange between different cloud-based and on-premise applications, systems, databases and even platforms.

The main reason behind that is that no business application is used as a standalone solution.
If your company uses a customer service system like Zendesk or Help Scout, you would need to integrate it with your CRM system like Salesforce or SugarCRM if you want to enable your support to immediately react to priority customers’ inquiries and issues.

The range of API implementations can go far beyond SaaS-to-SaaS integrations, though; in more complex digital transformation scenarios, it is quite a common practice to use APIs to connect IoT platforms to a lightweight integration middleware like iPaaS, and then connect the latter to a legacy ESB.

It shouldn’t come as a surprise then that APIs are gaining popularity with large enterprises, who use the application programming interface to share data with their partners and suppliers, and even to explore new market opportunities like in the case with IoT or Mobile.

Two methods to integrate with the help of API

Before I get to summing up characteristics of an API that would make integration a breeze, let’s quickly get through the basics of integration via APIs.

Basically, the mechanics of application and data integration is different depending on the quality of an API. You can either actively fetch data by polling an API or let an API send you data. Both methods have their pros and cons.

When you poll an API, you are in charge of data flow. If you need more data, you just specify that. If you know you have already too much of it so that it already got stuck somewhere along the way, you just decrease the amount of data you receive per request. This is important, because being in control of your data flow is highly relevant for a better performance of your integration as well as for guaranteeing that the data won’t get lost in case your storage is full.

The most obvious disadvantage of this method is that it can fail to deliver data in a real time mode. When you poll an API, you need to define clearly how often this will happen. Theoretically, you can poll it every other second, but most good APIs would impose limitations in terms of how often you’re allowed to do that and how much information you’re allowed to fetch in one go. So, let’s say you can schedule polling every three minutes. If data is processed faster than it is received, then you are bound to have delay in data processing.

The other method involves setting up a webhook trigger. In this case, an API would send data to webhook triggers on its own while they would just sit there and wait for it. It can be considered as an ideal solution, because then it doesn’t really matter how the API looks like. All you need is for the sending system to deliver data as soon as it is changed.

Another advantage is that you would have very little to no delay between data receiving and data processing, because it will be automatically processed as soon as it arrives.

But the drawback of this method is, opposite of polling an API, the lack of control of the data flow. The sending system will just keep delivering the same amount of data over and over again as soon as it will get confirmation that the previous batch was indeed delivered and e.g. stored in the message queue. There will be no way of limiting the amount of incoming data in case of emergency.

Characteristics That Make API Ideal for Integration

An API that is best fit for integration purposes is actually suitable for both methods described above. Sometimes, though, one is preferred to the other. And while the second method is more or less universal (if you remember, with webhook triggers, we don’t care about the quality of API), it is the first method that reveals if an API is good or not.

So, what are the qualities of a good API for integration and why are they so important?

1. Modification timestamps/ Search by criteria:
A good API should allow to search data by certain criteria, most importantly by its date. Simply because after the first initial data synchronisation, it is typically the changes that we are mostly interested in. In other words, we need the changed (updated, deleted, corrected, etc.) or added information since the last time we triggered the synchronisation.

So, when a trigger should poll data from API, the first important question to answer is how to detect changes in data.

The only way to get this data is to start asking for changes since particular timestamp. For example, the first, initial data synchronisation happened on May 01, 2016. So, we specify this date as a point of reference, and set up to request for data that has been coming in since this date. This is why it is important that in addition to search by criteria option, an API also provides timestamps.

2. Paging:

Naturally, it can happen that there are huge amounts of data, even if this is only the changed data. In order to deal with it efficiently, we need to have a way to specify that we need not all the changed data in one sitting, but, say, only the first “page” of it. For example, of the size one thousand data records.

This is what paging is about. A good API must be able to limit the amount of data that can be received in one go, as well as the frequency of requests for data. It should also be able to notify about how many “pages” of the data are left.

3. Sorting:
Paging can only work, though, when data is ordered, because if it’s not, it is impossible to know whether you’ve already received that data or not. Therefore, an API should also be able to allow to sort data at least according to time of modification.

So, having all these three characteristics allows us to define that we only need the data that came in after May 01, 2016, and only the first “page” of it, in our example, one thousand data records, ordered by time of change. Then we’ll remember what was the changed timestamp of the last record in this one-thousand records list, and then ask for next batch of data only starting from that moment. The mechanism for remembering timestamps can vary; we, for one, use snapshots for that.

Having said all that, if you use the OData protocol (preferably the latest version 4) to create APIs, then they will possess all the characteristics mentioned above by default, as well as some other, quite important ones like upserting an entity or conflict resolution (to avoid duplication of data).

4. JSON support / REST:
To be fair, an API doesn’t have to be RESTful in order to be considered good. However, most new APIs are REST APIs that, by default, support JSON, and there are quite a few good reasons for that.

REST APIs are stateless, which makes them ideal for applications that require a considerable amount of back-and-forth messaging, e.g. for mobile apps. If an upload to a mobile application is interrupted due to, say, loss of reception, REST APIs make it very easy to retry the process. With SOAP, this is possible too, but with considerably more effort. In addition to that, REST APIs are lightweight and more compatible with the web as they use simple URIs for communication.

REST APIs support various formats, with JSON being only one of them; TXT, CSV and XML would be other examples. This means that you as a developer has a choice between different formats (as opposed to SOAP that supports only XML), and can go for the one that really fits the purpose.

Using JSON with REST is considered to be best practice, though. Mainly, because unlike XML, JSON’s syntax is very close to most programming languages, which makes it very easy to parse it in almost any language. Not to mention that JSON is also really easy to create.

5. Authorization via OAuth:
OAuth is an open standard for authorization, and even though it is considered by some developers to be a pain in the …hm.. neck, OAuth provides considerably better usability for the application users/developers than any other method.

Contrary to widespread beliefs, OAuth isn’t equal to signing up with your Facebook or Twitter account; OAuth means that if application users (e.g. Xero users) want to connect this application with another one via some integration services, they can authenticate themselves by explicitly granting this service access to the application – no more, no less.

Unlike granting access with, for example, an API key, though, the OAuth authorization is considerably faster – you just need to click on a button confirming access grant. Any other method means that users of your API have to actually make an extra effort – not great for delivering superb user experience.

6. Good documentation:
It is last, but not least.
It seems like providing a good, extensive documentation for an API is something that should be understood by developers by default, you don’t need to point that out. Yet there is a massive amount of APIs that are extremely poorly described, even those APIs that are actually very good for integration.

Therefore, we can’t stress this enough how providing a solid documentation for API is important for integration projects, because it is one of the factors that drives the decrease in project implementation time, and hence, in costs for the project. And a good documentation surely does add up popularity to an API;-)

If you have other points to add to this list of characteristics that make an API great for integration, please do share them below. We’d love to learn about them!

TOP BEST API SECURITY TESTING TOOLS

API testing tools to the rescue

Having a critical networking and program component in the crosshairs of attackers is bad enough, but with APIs the situation is even more precarious because of the lack of standards involved in their creation. Many organizations likely don’t know how many APIs they are using, what tasks they are performing, or how high a permission level they hold. Then there is the question of whether those APIs contain any vulnerabilities.

Industry and private groups have come up with API testing tools and platforms to help answer those questions. Some testing tools are designed to perform a single function, like mapping why specific Docker APIs are improperly configured. Others take a more holistic approach to an entire network, searching for APIs and then providing information about what they do and why they might be vulnerable or over-permissioned.

Several well-known commercial API testing platforms are available as well as a large pool of free or low-cost open-source tools. The commercial tools generally have more support options and may be able to be deployed remotely though the cloud or even as a service. Some open-source tools may be just as good and have the backing of the community of users who created them. Which one you select depends on your needs, the security expertise of your IT teams, and budget.

Below are some of the top commercial API testing tools on the market and their main features, followed by some open-source tools.

Commercial API testing tools and platforms

APIsec

The APIsec platform acts like a penetration tool aimed at APIs. Whereas many tools can scan for common vulnerabilities to typical attacks like script injections, APIsec stress tests every aspect of targeted APIs to ensure that everything from the core network to the endpoints accessing it are protected from flaws in the API’s code.

One big advantage to APIsec is that it can be deployed in the development phase while APIs are being programmed. A full scan of apps that are in the process of being built takes only a couple minutes, with results comparable to old-school penetration testing operations that used to take days or weeks to complete.

AppKnox

AppKnox offers a lot of assistance to those who purchase and deploy their platform. Combined with its easy-to-use interface, this makes AppKnox a good choice for organizations that don’t have large security teams dedicated to their APIs. AppKnox starts with a scan to locate APIs either in the production environment, on endpoints or wherever they may be deployed. Once located, users can select which APIs they want to submit for further testing.

AppKnox tests for all the common problems that can cause an API to break or become compromised like command injection vulnerabilities in HTTP requests, cross-site tracing, and SQL injection vulnerabilities. This includes a complete analysis of web servers, databases and all components on the server that interact with the API.

After the API scan, users can submit their results for advanced analysis with a human security researcher, a process the company says normally takes between three and five days.

Data Theorem API Secure

The Data Theorem API Secure platform is designed to fit into any continuous integration and continuous delivery/deployment (CI/CD) environment to provide ongoing security to APIs in every stage of development and into the production environment. Its analyzer engine continually searches the network for new APIs and can quickly identify non-authorized ones or those that are part of the shadow IT at an organization.

The analyzer engine keeps itself up to date about the most recent vulnerabilities discovered for APIs and continually tests protected assets. It works with both on-premises and cloud environments to make sure that no APIs can fall victim to the latest threats. To keep the CI/CD pipeline clear and flowing, Data Theorem API Secure offers to automatically fix discovered problems without requiring human intervention. That way organizations can keep their APIs secure against even the latest threats, so long as they are comfortable with a high level of automation.

Postman

While Postman certainly qualifies as a testing tool for APIs, its claim to fame is as a complete and collaborative platform for building secure APIs. It’s used by millions of developers working in Windows, Linux and iOS environments, and for good reason.

Postman provides developers with a complete set of API tools to use when designing new APIs, and it also provides a secure repository for code that organizations can build up over time. Using the secure repository can ensure that future APIs maintain tight security and organizational standards from the start.

The workspaces provided by Postman are designed to help developers organize their work. It also can provide security warnings when an app’s code starts to drift away from the organization’s established secure template or incorporates a potential vulnerability. That way the problem can be fixed long before the API makes it to the production environment.

Smartbear ReadyAPI

In addition to security testing, the Smartbear ReadyAPI platform is designed to optimize their use and performance within any environment. It can execute an API security analysis with a single click, but it also supports other critical functions like seeing how well, or badly, an API can handle an unexpected load or sudden spike in usage.

You can configure ReadyAPI to generate the specific kinds of traffic that the API is expected to handle. It can also record live API traffic so that future tests will be more accurate and configured to the unique environment where it will be operating. In addition, the platform can import almost any specification or schema to test APIs using the most popular protocols. Natively, ReadyAPI supports Git, Docker, Jenkins, Azure DevOps, TeamCity and more, and can be run in any environment from development to quality assurance long before APIs go live.

Synopsis API Scanner

One reason why the Synopsis API Scanner is so powerful is because in addition to security testing, it also incorporates fuzzing as part of its suite of deep scans and tests. The fuzzing engine sends thousands of unexpected, invalid or random inputs to APIs to see how they behave or if they will break when subjected to things like very large numbers or odd commands.

It also maps out all the paths and the logic of an entire API, including all the endpoints, parameters, authentications, and specifications that apply to its use. This gives developers a clear picture of what functions they intend their APIs to perform, compared with what they actually might sometimes do. It makes it clear why an API might be subject to unexpected behavior or security vulnerabilities.

Open-source API testing tools

While the open-source tools generally don’t have the same support as commercial offerings, experienced developers can easily deploy them, often for free, to shore up or improve the security of their APIs. The following are some of the more popular offerings according to the open-source community.

Astra

Astra mostly concentrates on representational state transfer (REST) APIs, which can be extremely difficult because they are often constantly changing. Given that the REST architectural style emphasizes scalability in its interactions between components, it can be challenging to keep REST APIs secure over time. Astra helps by offering to integrate into the CI/CD pipeline, checking to make sure that the most common vulnerabilities don’t creep back into a supposedly safe REST API.

crAPI

The crAPI tool has a terrible name, but it performs its function as an API wrapper efficiently. It’s one of the few wrappers that can connect to a target system and provide a base path with the root client’s default set of handlers. It can do it without having to create any new connections. Advanced API developers can save a lot of time with it.

Apache JMeter

Apache JMeter, which not surprisingly is written in Java, began life as a load tester for web applications but has recently expanded for use with almost any application, program or API. Its detailed suite can test performance on either static or dynamic resources. It can generate a heavy simulated load of realistic traffic so that developers can discover how their API will perform under pressure.

Taurus

Taurus provides an easy way to turn standalone API testing programs into a continuous testing operation. On the surface, Taurus is simple to use. You install it, create a configuration file and let your testing tools do their work. If you poke under the hood a bit, you can discover ways to generate interactive reports, create more complex scenarios to put your APIs through, and set up failure criteria so you can immediately go in and fix discovered problems.

Drop your comment