Whether you are using a mobile native, web or desktop app, integrated devices like fitness trackers, smart thermostats and virtual voice assistants; the odds are, there are millions of application programming interface (API) requests happening every second to provide the necessary services to the consumers without them even realizing it. The present world runs on APIs and the adoption is only getting bigger. 

APIs have helped to share data efficiently across various ecosystems, have opened up new opportunities for companies to better serve their customers, and have continued to foster innovation. In fact, the Open API specification was formed in 2016, to help clients understand and consume services without knowledge of server code more seamlessly; thereby increasing efficiency. In summary,  API’s are the glue that binds systems together and it is here to stay.

APIs are a set of commands, functions, and protocols that programmers use to interact with an external system. They provide developers the ability to tap into different programs and perform different operations without having to build the program from scratch. 

RELATED ARTICLES:
APIs help developers do more with less
Debunking the API revolution

The biggest advantage of APIs is the level of abstraction they provide by exposing only the data that are needed to communicate with another system. For example, Google’s Maps API is used by number of organizations to provide Google Maps support instead of companies having to build their own maps application. The same holds true for Mint, the finance app that connects via APIs to different banks to fetch the required customer data. 

How do APIs work?
On a high level, API communication is a three-step process:

  • Step 1 — A client/application sends an API request to the server The request contains an API key to uniquely identify the sender
  • Step 2 — The request then goes to a server and the API key gets validated to ensure the sender is credible
  • Step 3 — Based on the validation, a response is sent back to the client/application

REST and SOAP are the most commonly used API paradigms. REST (Representational State Transfer) is an architectural style that defines a set of constraints for creating web services. SOAP (Simple Object Access Protocol) is a protocol that defines the way structured information is exchanged within web services. There are considerable differences between the two and each one has its own advantages and disadvantages.

Testing APIs
In the past, APIs were developed on an ad hoc basis; it was acceptable to leave them to be vetted and tested by developers alone. However, now APIs can be seen as a separate product offering in and of itself that support a company’s strategic vision; therefore, a more robust approach to testing APIs is required.

The main questions to consider as part of API testing include:

  • Is the API public-facing or internal? 
  • Is it necessary to integrate with components outside the system or application?
  • What are the endpoints and value types? 
  • Where is the data coming from? Can the data be accessed freely or is some sort of key or authentication required?
  • How will you verify the expected result? How will it be determined if the API performed as intended under the specified circumstances or scenarios?
  • Is the API logic simple or is it more sophisticated; with dependency-based decisioning?
  • Under what conditions is a site, app, or function most likely to fail?

In addition to the above considerations, API testing should not be limited to just making a few ‘Get’ and ‘Put’ calls to verify that the values are returned as expected.  Developers tend to limit their unit tests to this type of straightforward verification. With APIs, testers need to be especially attuned to not only individual functions, but also the end-to-end sequence of events, calls, responses, and downstream events. At the very least, the most common and basic scenarios to test are:

  • (GET) Results are returned as expected
  • (POST) All parameters are passed and/or received as expected
  • (PUT) Inputs are correctly captured and stored
  • (DELETE) Deleted data is cleared from the database
  • Error messages are meaningful and returned as expected
  • Triggers for downstream events occur as intended
  • For security, testing should also include scenarios for controlled access, authentication, and encryption

The above scenarios can be mixed and matched and in many ways. Also, just like automated tests for functional testing, API tests can be automated as well; to get faster feedback and adequate API testing coverage. 

API testing is a vital part of the overall testing strategy. It should cover three primary aspects: connectivity, response, and performance.

  1. To test connectivity, simply make a call to the API using its URL. If a 200 response is returned, the API is connected. If no response is returned, or a connection failure error is returned, then connectivity failed; which means that the request was not received by the server.
  2. It is important to ensure you get back the correct responses for different API requests. The validation includes looking for the correct values to be returned in the response along with the appropriate status code. The values returned are specific to the type of API that is implemented but in terms of status codes. Below are some commonly validated status codes in API testing:
    • 400 BAD REQUEST – Generic error that is returned when no other 4xx status code is appropriate. Domain validation errors, missing data and improper API requests are some examples.
    • 401 UNAUTHORIZED – Error code response for missing or invalid authentication token.
    • 403 FORBIDDEN – Error code response when the user is not authorized to perform the operation 
    • 404 NOT FOUND – Used when the requested resource is not found, it doesn’t exist or if there was a 401 or 403 error and for security reasons, the service masks it as a 404 error
    • 409 CONFLICT – Response for resource conflicts, for example, duplicate entries are found or trying to delete root objects when cascade-delete is not supported
    • 500 INTERNAL SERVER ERROR – This error code is returned when the consumer cannot identify the exact error from their end. It is a general catch-all error when the server-side throws an exception. 
  3. An API’s performance can be said to be its most valuable feature. Each time an API request is made the response needs to come back in a matter of milliseconds. Also, depending on the application, thousands if not millions of API requests can be made, as in the case of Facebook, Google and Twitter. This being the case, the APIs should be able to handle large amounts of load without failing. If it does not have fast response times and unable to handle load amounts of request; the API is pretty much worthless. 

Also, It’s not just about the number of users that an API can handle, but also about how efficiently does a given API perform? How many additional web service calls are getting generated or how many times is it hitting the database? 

These are the types of questions that must be answered for an API to be ready to perform in the current marketplace.