Many software testers may perceive that the software testing landscape is changing. More and more testing positions are requiring you to have coding abilities. The software industry as a whole is evolving. It’s no longer just about installing a program on your computer. A vital skill for testers will be the ability to swiftly learn and analyze an API. To be a good tester in this field, you don’t need to know how to code, but you need to understand APIs and their function. Let’s discuss the fundamentals and concepts for effective API testing 🔍
API (Application Programming Interface) is a computer interface that allows two different software systems to communicate and share data. A software system that performs an API contains numerous functions/subroutines that can be performed by another software system. Between two software systems, an API describes the types of requests that can be made, how they may be made, the data formats that may be utilized, and so on.
Table of Contents – API Testing 101
- What is a WebService?
- WebService and API are not exactly the same
- Understanding API terminology
- Types of APIs
- Getting Started with API Testing
- API Authorization
- The risks of relying on services and APIs
- API Mocks for Testing
- API Testing Methodology
- API Test Automation
- Additional API Testing types to Consider
- Happy API Testing Folks!
What is a WebService?
A Web Service is a standards-based, language-independent software entity that receives specially prepared requests from other software entities on remote machines and responds with application-specific responses via vendor, and transport-neutral communication protocols.
WebService and API are not exactly the same
API and Web service serve as a means of communication. The difference is that a Web service facilitates the interactions between two machines over a network. An API acts as an interface between two different systems so that they can communicate with each other. An API is a method by which the third-party vendors can write programs that interface easily with other programs.
A Web Service is a type of API that: 📝
- Is used to transmit data between applications
- Follows a W3C standard
- Has an interface that is expressed in a machine-processable format called a WSDL (Web Service Description Language)
- Nearly always uses HTTP
SOAP, REST, and XML-RPC are examples of web service protocols. The Linux Kernel API, which is written in C for usage on a local machine, is an example of a non-web service API 💻
Understanding API terminology
When we get into the nitty-gritty of API testing, it’s important to know the terminology. These are phrases that are often used in the API world, and they assist us in thinking about and testing APIs. API Nouns are basically the URIs that you would use when making the API Request.
GET
Use GET requests exclusively to get resource representations/information, not to change it. GET requests are considered safe because they do not modify the state of the resource. Furthermore, GET APIs should be idempotent, which means that making repeated identical queries should always return the same response until another API (POST or PUT) changes the state of the resource on the server.
If the Request-URI refers to a data-producing process, it is the produced data that shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process 📤
Example request URIs
- HTTP GET http://www.domain.com/employees
- HTTP GET http://www.domain.com/employees?size=20&page=5
- HTTP GET http://www.domain.com/employees/123
- HTTP GET http://www.domain.com/employees/123/address
POST
To create new subordinate resources, use the POST APIs. For example, a file is subordinate to the directory that contains it, and a row is subordinate to a database table. POST methods are used to add a new resource to the collection of resources when speaking strictly in terms of REST.
Unless the response includes the necessary Cache-Control or Expires header fields, this method’s responses are not cacheable. Please keep in mind that POST is not secure nor idempotent, therefore sending two identical POST requests will result in two separate resources containing the same data (except resource ids).
If a resource has been created on the origin server, the response SHOULD be HTTP response code 201 (Created) and include an entity that specifies the request’s status and references the new resource, as well as a Location header. Frequently, the POST method’s operation does not result in a resource that can be identified by a URI. The proper response status in this scenario is either HTTP response code 200 (OK) or 204 (No Content) 👩💻
Example request URIs
- HTTP POST http://www.domain.com/employees
- HTTP POST http://www.domain.com/employees/123/accounts
PUT
PUT APIs are mostly used to update existing resources (if the resource does not exist, then API may decide to create a new resource or not). The origin server MUST inform the user agent via the HTTP response code 201 (Created) if a new resource has been created by the PUT API, and if an existing resource has been modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the request is cached and the Request-URI specifies one or more currently cached entities, those entries SHOULD be considered stale. This method’s responses are not cache-able.
Example request URIs
- HTTP PUT http://www.domain.com/employees/123
- HTTP PUT http://www.domain.com/employees/123/accounts/456
PATCH
PATCH requests are used to make a partial update to a resource over HTTP. PUT requests also affect a resource object, thus to be clear – the PATCH method is the best choice for partially changing an existing resource, whereas PUT should only be used if you’re completely replacing a resource.
Example request URIs
HTTP PATCH http://www.domain.com/employees/1[
{ “op”: “replace”, “path”: “/mobile_number”, “value”: “7187187187” }
DELETE
The DELETE command is idempotent. When you DELETE a resource, it is no longer part of the collection. Repeating the DELETE API request on that resource will have no effect; however, using DELETE on that resource a second time will result in a 404 (NOT FOUND) because it has already been removed ❌ It’s possible that this renders the DELETE method non-idempotent. It’s a question of debate and personal preference.
If the request is cached and the Request-URI specifies one or more currently cached entities, those entries SHOULD be considered stale. This method’s responses are not cache-able.
Example request URIs
- HTTP DELETE http://www.domain.com/employees/123
- HTTP DELETE http://www.domain.com/users/123/accounts/456
Types of APIs
- REST: When you create a REST API, you’re following a set of guidelines put down in Roy Fielding’s Ph.D. thesis. These are a collection of guidelines for creating APIs that are consistent and easy to use. Most APIs built today are RESTful in nature, and if you’re not sure what kind of API you’re working with, RESTful is a good estimate. REST is a collection of architectural principles rather than a protocol like other web services. The REST service must have specific properties, such as simple interfaces, which allow resources to be recognized quickly inside the request and resources to be manipulated through the interface.
- SOAP (Simple Object Access Protocol): This is a protocol that uses XML as a format to transfer data. Its main function is to define the structure of the messages and methods of communication. It also uses WSDL, or Web Services Definition Language, in a machine-readable document to publish a definition of its interface.
- GraphQL: GraphQL is kind of trying to bridge the gap between REST and SOAP in some ways, so it’s a little bit more standardized rules, but it still has some of the freedom of REST APIs.
GraphQL is both an API query language and a runtime for executing those queries using your current data. GraphQL allows clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools by providing a clear and comprehensible description of the data in your API.
- Hypermedia: Hypermedia APIs are systems that want a consuming API (the programmed client) to do that as well. Hypermedia APIs accomplish this by responding to requests with both the requested data AND other resources available or actions to take.
Getting Started with API Testing
If you are new to API Testing and looking out on where to start, clients like Postman would be a good place to start. Check out this blog written by Dave Westerveld to get started. And then proceed to this blog for a more advanced approach 😊
API Authorization
Authorization and Authentication
Let’s understand the difference between authorization and authentication. Authentication is all about proving who you are, while authorization is all about proving what you can do. That sounds fairly abstract, and it’s difficult to wrap your head around 😓
Let’s pretend you’re in a restaurant and want to order an alcoholic drink 🍷 They demand to see your identification. They can both authenticate and approve you using your ID. They can verify that you are who you claim you are by comparing your photo to the one on your ID. They can also verify that you are using the correct identification and allow you. They can figure out how old you are and if you’re old enough to be provided alcohol by looking at your birth date. Now, in API security, we normally mix authorization with authentication, just like we do with your ID. As a result, you only need to provide one token, or one ID badge if we consider it an ID, which can be used to verify both your authentication and authorization in one step ✅
OAuth Tokens
OAuth is an open-standard authorization protocol or framework that allows programs to grant “secure designated access” to users. You can, for example, notify Facebook that ESPN.com can access your profile and post items to your timeline without giving ESPN your Facebook password. This significantly reduces risk: even if ESPN has a data breach, your Facebook password is secure. OAuth does not disclose password information, instead of relying on permission tokens to establish a connection between users and service providers. OAuth is a security mechanism that allows you to authorize one application to engage with another on your behalf without disclosing your password.
More info on how you could obtain bearer tokens and basic tokens can be found here.
AWS Signature
The practice of adding authentication information to AWS API requests transmitted through HTTP is known as Signature Version 4 (SigV4). Most AWS requests must be signed with an access key for security reasons. The access key is made up of two parts: an access key ID and a secret access key, which is also known as your security credentials. You can read more about it in this article 📖
The risks of relying on services and APIs
There are numerous advantages to using APIs and web services. A web service allows you to isolate elements of your application, and using an API to retrieve data from it allows you to delegate some of the work, allowing you to focus on the user interface rather than business logic. There are numerous advantages that can be obtained. The use of APIs can provide a slew of advantages, but they too have their risks.
API Changes that could occur that we should look out for before testing:
- Schema/Structure
- Data formats
- Versions
- Server manipulations
- Availability
- Permission changes
- Network issues
- Calls that are out of order due to slow responsive calls
- Risks involving concurrent changes such as concurrent POST, PUT, and PATCH calls
API Mocks for Testing
Sending requests to an API and reviewing the answers is the quickest method to learn what it can do. It can take weeks to make active calls available during the initial creation of an API. To return example API mock results, you can build against an API in parallel online. Furthermore, by obtaining input sooner and iterating before developing code to service a production API, you can design a better API 😀
What is a Mock API Server, and how does it work?
A mock API server, also known as a mock server API, simulates a real API server by responding to requests with realistic mock API answers. They could be on your local machine or on the Internet at large. Responses might be static or dynamic, and they imitate the data that a real API would return, with data types, objects, and arrays that meet the schema.
Why Should You Use API Mocking?
When live data is unavailable or unreliable, a mock API server comes in handy during development and testing. Mock APIs can be used to work on the front and back ends of an API at the same time, as well as to get feedback from developers. Our guide on using a mock API server for testing explains how to use one so that the lack of a real API doesn’t hold you back 👊
Mock APIs can also be used to simulate APIs that you don’t have control over. When you aren’t connected to the Internet, you can utilize a local mock server to simulate results from a public API. Alternatively, if actual API requests would result in a fee from the supplier, utilize dummy data answers.
For unit testing, you could use mimic API calls. You may not want to wait for dozens of live calls to an external API when your tests run with every delivery. You can unit test the rest of your code using a mock API server or library that returns expected results. Keep in mind that you’ll need to use another method, such as API contract testing, to ensure that API replies fulfill your expectations. To learn how to create mock servers refer to this blog.
API Testing Methodology
Before watching and reporting the system’s response, a tester should concentrate on using software to make API calls in order to receive an output. Tests that the API produces a correct response or output under a variety of situations.
This result is usually one of the following three:
- The result is either a pass ✅ or a fail ❌
- Information or data
- A call to a different API
However, there could be no output at all, or something unexpected could happen. As a result, the function of the tester is critical in the application development process. Data-driven testing for APIs can assist boost test coverage and accuracy because APIs are the major hub of data for many applications.
Specifying pass/fail scenarios when testing the API directly is a little more difficult. Comparing the API data in the response or the behavior after the API call in another API, on the other hand, would assist you in setting up definite validation scenarios.
API testing is one of the most difficult aspects of the software testing and QA testing process since it ensures that our digital lives are becoming more fluid and efficient. While developers tend to test only the features that they are working on, testers are responsible for evaluating both individual functionalities as well as a series or chain of capabilities to see how they interact from beginning to end 🔚
API Test Automation
The APIs can be tested using a variety of tools. When a tester is assigned to test an API, they must first obtain the API’s documentation 📃
Typical API documentation includes all of the API’s details, such as the request format, response, error codes, resource, mandatory parameters, optional parameters, headers, and so on. Various open-source tools, such as Swagger, can be used to maintain the documentation.
Because APIs are frequently faster and lend themselves well to automated testing, it’s generally advantageous to use them for test automation. We often consider test automation to be only an extension of our exploratory testing, and exploratory testing certainly provides insight into what we need to automate.
Exploration and automation, on the other hand, are usually attempting to accomplish distinct goals, so we must think about them in different ways. Exploration can help us set the groundwork for the automated test we wish to run. Exploration, on the other hand, is about discovery, about discovering new things, and it’s about figuring out what else we might need to examine or dig into in the system 👀
Automation is more about doing the same thing over and over again. As a result, they’re not the same. Automation and exploration are comparable and intertwined. In order to be implemented, automation relies on exploration. They aren’t, however, the same thing. So, if we need to automate something, what exactly do we need to automate? There are a few things we should think about. Things that do not change are one of them. If we automate these, we know that any changes in them, as well as any failures in our automation, should be investigated further. Another thing to consider is items that you’d like to be aware of if they change.
API Test Automation Techniques
- Data-Driven- Examining each endpoint or combination of endpoints so it is looking at what data is available in the system, and what things do we need to iterate or repeat over and over again 🔁
- Workflow- Driven – Making a number of API calls in order would simulate the type of workflow a user may utilize. In this example, we’re testing it out more in the manner of a consumer. We’re using a process that a customer may use.
There are many tools that can help you create API Tests and Automated tests such as Postman, TestProject, Rest-Assured, JMeter, etc. You can find details about such tools here 🤩
Additional API Testing types to Consider
- Unit Testing – Individual operation functionality must be tested. Google, for example, provides a geocoding API that may be used to determine the longitude and latitude of any location. This normally accepts an address and returns lat-longs. The tester can now use different locations to unit test this API and validate the results.
- Performance Testing – An API can be a useful tool for obtaining the information you require. They can provide you programmatic access to particular system capabilities while also including enough of the system to give you a realistic sense of how it might be utilized in real life. So, when it comes to performance testing, APIs are a terrific approach to help you out:
- Load Testing
- Speed Testing
- Requests made per Second
- Number of items a Page could Load
- Stress Testing
- You could again use tools like Postman, JMeter, etc. to conduct such tests.
- Security Testing – SQL injection and cross-site scripting are examples of vulnerabilities. These flaws can also be found in APIs, according to reality. In reality, attackers frequently investigate these issues at the API level. I’ve said that a couple times already in this course, and it’s still true here. APIs lend themselves nicely to automation, therefore when attempting to hack a site, the ability to automate and try different things is advantageous to the hacker, and they will frequently attempt to exploit these weaknesses via the API. As a result, you should double-check for these common security threats.
- API Testing and the Internet of Things – Because APIs are used for the majority of data sharing within IoT devices, testing the API of an IoT-capable device is critical. APIs make data available, allowing different devices to link and combine to create new and exciting workflows. APIs are programs that serve as a connection point between the Internet and things.
- Microservices and API Testing – The number of smaller APIs that need to be tested grows as the Microservices design breaks down a single large system into several little parts. These contracts’ Quality Assurance is critical for keeping the firm up and running and ensuring business continuity even after upgrades. Integration with automated test execution and fail-fast systems is critical for business continuity, as is providing predictive support and addressing dependency concerns ahead of time. Many of Aspire’s customers have benefited from its knowledge and ready-to-use automated frameworks in ensuring quality first delivery.
Happy API Testing Folks!
In our internet-connected world, API testing is a critical skill for testers to possess. This article covers all the information that a beginner needs to know before she/he dives into the world of API Testing. You’ve got the foundational pieces you’ll need to get started with API testing, but there’s still a lot more to learn. This is a topic with a lot of room for further study. There are numerous API testing tools available to assist you in completing your task. TestProject Blog consists of more in-depth documentation that would help you in your voyage of API Testing. Good Luck! 🧡