API and Webservices are two commonly used terms when we talk about client-server communication. Testing plays an important role in building quality APIs and web services. While they are similar to some extent, they are sometimes confusing when to use what.
In this article, I will be covering a few basic things to know about web services and API in a simple way, the differences between them, and how we test them.
What is API/Web Services?
Web services/APIs are used to communicate and exchange data between two systems or applications. API stands for an application programming interface. In simple terms, we can say, when two applications cannot communicate directly, we use the API/web services. By definition, both APIs and web services are the same. They overlap with each other. But as two terms exist, there is a difference between them. Both API and web services are often confused with each other.
Source: https://testautomationresources.com/
Now let us see the differences between them.
Difference between API and Web Services
API is a utility created by a system and it is sold as a service to 3rd party systems. If we want to integrate 3rd party utility/dependency in our system, we use API. When we need the same services/API over the web using the HTTP protocol, we use web services. Let us understand this with examples.
Hotstar app uses the Google interface to log in to the app. Now how is this possible? Google has created a web service/ API so that any authorized third-party application can use Google APIs for login to its application.
Similarly, MakeMyTrip uses AirAsia’s web services/API to display flight details on their website. The services/endpoint offered by Air Asia is via the web using the HTTP protocol, and MakeMyTrip has the authorization to access them.
The examples above show that API and web services are the same. But then what is the difference?
If you have written a set of code as a utility so that it can be reused in other programs of yours, this is also an API. This is not a web service. This is present in your local system and can be used whenever you want to reuse the code. So if a system has built a utility and another system uses it, and the utility exists in the local system, this is exclusively an API, not a web service.
So, all web services are APIs, but all APIs are not web services.
WebServices/API Testing
When we talk about web services/ API, we mostly discuss client-server communication. An application has two layers. The front-end layer is the one with which a client interacts. Then we have the back-end layer where data is stored. In between the front-end and back-end layers, we have a business layer where all communication happens based on this layer. Business logic and back-end layers form the server.
A client requests, and it waits for the server to respond. In between, the API/web service acts as the middleman, and the response is sent back to the client. Both client and server are written in different languages. The testing of a business layer is called API/web services testing.
The test approaches are almost the same for both web services and API. The difference is that Web Services are available in servers but for API, servers/browsers/URLs are not mandatory. Because APIs can be available locally. Developers can give the APIs in the form of jar/dll/exe file to the testers so that they can test them directly. We don’t need a browser. Web services, on the other hand, will be present in a remote location. The tester has to send requests through a URL in order to test a web service.
Why API/Webservices testing is Popular?
When we open any website, the request is sent by the user. The request is sent to the API. The server will respond to the API and give some output as JSON/XML. Then it is presented to the user in HTML/CSS/js. API testing popularity has increased as we can test the API easily by validating the JSON/XML as compared to front-end testing which is more time-consuming. API Testing is also faster.
Webservices/API Testing Types
1. Contract Testing:
Contract testing is used to ensure that services between API provider and consumer are working as expected. Providers can update/change the API service only with the consent of the client/consumer. A tester has to validate the API structure/specifications as per the contract.
For contract testing, tools like Pact and Spring Cloud Contract are used.
2. Component/ Module Testing:
This can be assumed as unit testing in APIs. Each module or component is tested in isolation in this type of testing. The request payload structure and the response are validated with the expected output.
Testing includes the following :
- The request payload is as per the API specification.
- The data types are valid and as expected.
- The response payload format is as per the specification.
- The error codes and the status are as per the agreement.
- CRUD operations are performed as per the requirement ( POST, GET, POST, DELETE).
Tools like Postman-Newman, JUnit, Rest assured are used for this type of testing.
3. Scenario Testing:
Once the individual modules are tested in isolation, the integrated modules together are tested. There might be several APIs in sequence when an application is being built. So Integration testing focuses on testing all the APIs in sequence and validates the expected output.
Let us take an example of a shopping site. A user wants to buy a book. He adds the book to the cart. Then he completes the payment process, and the order is successful. Scenario testing focuses on end-to-end testing of the application
Let us take the same example to understand what type of defects are caught in this type of testing. The user adds the book to the cart at a specific time. The API which is used for this purpose gives a response that has a DateTime attribute in milliseconds. This DateTime attribute is again used in the API that is used for completing the payment.
But the DateTime attribute accepted in the second API should be in seconds. As there is a mismatch in these 2 APIs when running in sequence, adding to the cart will be successful, but payment will fail. These types of partial failures are detected in scenario testing
Postman and Cucumber is used for scenario testing
4. Performance Testing:
Performance testing is much needed to check that the SLA (service level agreements) are met for the APIs. Performance testing is performed by loading the integrated /scenario tests to any API performance tool and run simultaneously with a higher number of users. There are alert mechanisms by which developers/testers can monitor the system for high load and can debug when a performance test fails. We test the following in performance testing.
- Latency
- Error rates
- Concurrency
- Rate limiting
- There are various performance tools like JMeter, Octoperf, and K6.
5. Security Testing:
Security testing is done to ensure that the APIs are built in a secure fashion and are protected from any vulnerabilities and malicious attacks. Security testing involves the following.
- Authentication & Authorisation of a user: This ensures who has access to what (role-based access )
- Data leakage
- Fuzzy Input parameters
- Injection vulnerabilities like XSS, SQL injection
- Tools like Postman, Karate, fiddler, JMeter are used for API Security testing.
6. Omni-Channel Testing:
There are various interfaces an application has to interact with, like mobiles, Web, APIs, and databases. There might be severe issues if any of these are tested in isolation. So omnichannel testing coordinates all the interfaces. The API tests are combined with mobile and web UI testing. We use a variety of tools for Omni-channel testing like Selenium, Katalon, Postman
Conclusion:
API/Web Services testing is easy to maintain and is consistent as compared to UI tests. An automated test strategy and continuous deployment can be very helpful in API testing to check the APIs are meeting the business requirements and also functionally precise.
