An Application Programming Interface (API) at its core is a formal specification that acts as a guaranteed contract between two separate pieces of software. Modern computer systems are generally designed using the ‘layered architecture approach’:
This means that the core functionality of the system is contained within the “business logic” layer as a series of discrete but connected business components. They are responsible for taking information from the various user interfaces (UIs), performing calculations and transactions on the database layer and then presenting the results back to the user interface.
However, in addition to communicating with human beings via the UI layer, computers systems have to be able to communicate directly with each other. For example, your mobile ride sharing application will need to communicate with the mapping service, the traffic and weather services and other specialized applications used by the drivers providing the rides. In the modern, interconnected world, we take for granted that all these different systems can speak to each other seamlessly, in reality that would not be possible without APIs.
As mentioned above, an API enables a sort of “communication” between two separate pieces of software. The API provider defines the set of operations, data formats and protocols that it expects. The consumer of the API (called the client) will use those rules on the understanding that, as long as it follows the rules, the client will always be able to use the API without having to worry about the internals of the API itself:
The importance of APIs is that it allows different organizations to create software applications that rely on other applications and services without having to constantly update their application when the internals of the dependent applications or services change. As long as the API itself remains stable, the internal implementation can change. This is due to the two primary components of an API working together:
So, what happens when you want to change an API and expose new functionality? In most scenarios, you will have two choices:
So now that we have established what an API is and why APIs are critical to modern interconnected, globally distributed applications and services, it is important to understand why the testing of those APIs are critical.
As mentioned above, this process involves testing the application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security. To achieve this, APIs are typically tested with extreme conditions and inputs to record the outputs and evaluate how they perform. The goal is that if it passes these various tests and scenarios, the API should have no issues when exposed to normal usage.
The move to cloud computing has highlighted the importance of APIs. With this rise in cloud applications and interconnect platforms, API testing is a necessity to ensure that everything runs smoothly and works together. Many of the services that we use every day rely on hundreds of different interconnected APIs, so if any one of those links in the chain fail, the service will at least be hindered, or possibly even stop functioning entirely
Two major types of software testing that can sometimes be confused are API testing and GUI (graphical user interface) testing. While they are both testing interfaces, the different processes relate to the two interface types we mentioned at the beginning. API testing is a testing method of verifying that the web API responds to requests from the client applications in the correct way. GUI testing is a method of verifying that the user interface behaves as expected.
Since APIs lack a GUI, API testing is performed at the message layer. API testing is critical for automating testing because APIs now serve as the primary interface to application logic. This is also because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps.
When you release a new version of the system (e.g. changing some of the business components or internal data structures) you need to have a fast, easy to run set of API regression tests that verify that those internal changes did not break the API interfaces and therefore the client applications that rely on the APIs will continue to function as before.
When looking at an API testing tool, it is important to understand which API technologies you will be using and how best to test them. Nowadays most APIs you come across will be of the Web Service variety (either REST or SOAP), but you may come across other technologies such as Java EJBs or Microsoft DCOM/ActiveX DLLs.
A Web Service is a unit of managed code that can be remotely invoked using HTTP, that is, it can be activated using HTTP requests. Web Services allows you to expose the functionality of your existing code over the network. Once it is exposed on the network, other application can use the functionality of your program.
There are two broad classes of Web Services:
Simple Object Access Protocol APIs make use of the Web Service Definition Language (WSDL) and communicate using HTTP POST requests. They are essentially a serialization of RPC object calls into XML that can then be passed to the web service. The XML passed to the SOAP Web Services needs to match the format specified in the WSDL.
SOAP Web Services are fully self-describing, so most clients do not directly work with the SOAP XML language, but instead use a client-side proxy generator that creates client object representations of the Web Service (e.g. Java, .NET objects). The Web Service consumers interact with these language-specific representations of the SOAP Web Service.
However, when you are testing SOAP services as well as having a nice interface for viewing the provided services and invoking test operations, you need to always have a way to verify the raw SOAP request and response packets being sent in XML:
This feature, in particular distinguishes a true SOAP solution from merely a SOAP client library. The former helps you test the service and understand failures, whereas the latter is just a way of making SOAP Web Service calls more easily from different programming languages.
In addition, you ideally want to be able to generate your test scripts programmatically from the invoked endpoints and automatically include validation checks:
The following features should be looked for in a SOAP Web Service testing tool:
A RESTful web API (also called a RESTful Web Service) is a web API implemented using HTTP and REST principles. Unlike SOAP-based Web Services, there is no "official" standard for RESTful web APIs. This is because REST is an architectural style, unlike SOAP, which is a protocol.
Typically, REST Web Services expose their operations as a series of unique "resources" which correspond to a specific URL. Each of the standard HTTP methods (POST, GET, PUT and DELETE) then map into the four basic CRUD (Create, Read, Update and Delete) operations on each resource.
REST Web Services can use different data serialization methods (XML, JSON, RSS, etc.). However, the format used for REST Web Services has traditionally been XML. This is partly because it was used extensively in SOAP Web Services and is therefore familiar, but also when bandwidth is not a limiting factor, it is self-describing, with the fields and data clearly described:
When choosing a tool to perform REST Web Service testing, you should look for:
Outside of Web Services, the other API technology you might come across is Microsoft DCOM or ActiveX. Microsoft's Component Object Model (COM) also known as ActiveX is a standard for communication between separately engineered software components. Any object with a COM interface can be created and used remotely:
var doc = new ActiveXObject("Word.Application");
Using this approach, any API packaged as a COM or .NET accessible Dynamic Linked Library (DLLs) can be tested natively by testing tools such as Rapise.
Rapise from Inflectra provides support for testing the following different types of DLL API:
If you’re ready to upgrade how you test APIs and other software, Rapise has a wide array of tools that are trusted by some of the top software developers in the industry. Available on several platforms to fit your needs, Rapise simplifies all aspects of your testing process to deliver the reliability and insights you need for your software. Click the button below to get started with a free trial today!
And if you have any questions, please email or call us at +1 (202) 558-6885