animind - Fotolia
Developers can create or use several means that enable applications to communicate back and forth. Of course, QA staff must assess these vital components of the software.
APIs and web services are both ways for applications to exchange data. However, API and web services testing are different endeavors. To efficiently test each component, understand how it fits within the blueprint of the application. And use a comprehensive QA approach, from stress testing to security scans to functional tests.
APIs vs. web services
A web service is like an application that another client application accesses. That client application retrieves the data it needs through the use of Simple Object Access Protocol (SOAP) or REST protocol. SOAP and REST follow standard internet methods of communication and return data in formats such as HTTPS and XML. A client application, for example, can make a request to a web service in the form of an XML message. It will then await a reply from the web service in the form of another XML message.
Web services are simple to develop and deploy. With XML, web services developers can create small components, which they combine to create complicated communications structures.
APIs are protocols or interfaces -- sometimes both -- that allow two distinct pieces of software to exchange data and use each other's functions. Think of APIs as calling conventions and a subset of web services. APIs include procedures and functions so applications can request and send information. APIs are flexible; they can use any type of communication.
Key terms for web services and APIs
REST and SOAP are types of messaging protocols, sometimes called architectural styles. They're options developers have for accessing other applications. HTTP and XML are languages used to write out the requests and responses between applications. A SOAP message can be written in XML, for example, and, in the same vein, a REST message might be based on HTTP principles.
APIs and web services testing
Web services testing assesses the function that application is supposed to provide. Testers check if a web service can provide a client application the response it needs.
The aspect of the API under test is the communication it facilitates -- not so much whether the service on the other end performs the function it's supposed to when a client app pings it.
QA for both APIs and web services should cover functional and nonfunctional tests. Test code should call for and receive information using the interface, and then the tester verifies the results. Web services testing should also involve stress and load tests, as well as checks for reliability and security. API and web services testing both require setups beyond most test cases, so choose tools that work well for the protocols and languages in use.
Commercial and open source tools provide features like test harnesses and API simulators for these types of tests. SmartBear offers SoapUI for web services testing, with both a free version and more feature-rich commercial product. SoapUI is easy to use and can handle both functional and nonfunctional tests. Postman, a language-agnostic platform for API development, enables testers to write scripts in the same language as the API.
Dig Deeper on Testing APIs, microservices and distributed systems
Related Q&A from Gerie Owen
A script-based tool has replaced a daily testing exercise on some code. Is it simply an automated test, part of a test automation strategy or even ... Continue Reading
Developers and testers strive to create quality, reusable code to deploy apps faster and keeps users happy. But what metrics should they track to ... Continue Reading
Don't get stuck in QA monotony. Show your technical knowhow and expand your horizons to boost your career -- even if it means throwing out the map. Continue Reading