An API, or Application Programming Interface, is a set of rules that define how computers and applications can communicate with each other. If you recall the old switchboards that operators used to field phone calls to their destinations, APIs are a little like that. A client makes a request to an API at an endpoint which it has access to. The API validates the request and passes the request to the destination server or program. The server sends a response back, first through the API, which then transfers it back to the client.
APIs also provide a lot of functionality to developers. Imagine if every web shop that wanted to process credit cards had to write their own credit card processing code. It would take forever! Instead, developers can call the PayPal API with their software to securely process credit card payments. APIs are a little bit like external function calls, if you're coming from a desktop programming background.
APIs are a great solution to many programming problems, but what happens when they break? And how can engineers stay out in front of the problem?
When we request a resource with HTTP, an HTTP response is returned, even if our specific request wasn't fulfilled as we intended. This is like visiting a website and getting a 404 error code instead of content. Some common HTTP responses are:
We can use these responses to test our API endpoints. It's like visiting the website above and seeing if it works or not, but with more options than just viewing content.
You may recall from What is an API Call? that there are four main types of requests in an API. Since they do different things and expect different responses, they are different test cases. Let's try a GET request at the Holidays API:
```httpcurl -v 'https://holidays.abstractapi.com/v1/?api_key=e0b6e663bb8041f2ba535c3f0ec7a791&country=US&year=2020&month=12&day=25'```
Examine the output. Notice the `< HTTP/1.1 200 OK` line? That's our HTTP response code. We have successfully tested a GET request at this endpoint!
Now, it would take forever to do this point by point, wouldn't it? Of course, there are automated test systems out there to solve this problem on a larger scale in a CI/CD pipeline. How do they work?
The smartest way to test APIs is to test continuously with automation, as part of a CI/CD pipeline. This means that testing is a part of your deployment- when changes are made to your repo, a new build is triggered and tested. So if a new API version appears and messes everything up, you're aware of the problem instantly, and can make changes to correct it.
Of course, just knowing our program works with functional testing, doesn't mean we can't improve it with load testing, performance testing, and stress testing.
APIs are great at building modular solutions, but they need to be tested often to ensure they're operating correctly. API platforms like Postman and Smartbear offer software to automate your large-scale API testing solutions, or you can go endpoint-by-endpoint on your own. Or maybe you can come up with a better way altogether!