Breaking Down a Web Service

 6Understanding the pieces of the web service testing puzzle can make testing easier

For people wanting a broader understanding of more pieces in the web service testing puzzle, here is a breakdown of the various possible components of an API.

These descriptions and the glossary can be the foundation for further learning on testing web services. The description is compiled from a few sources:

Web service APIs

A web service is a piece of software, or a system, that provides access to its services via a URL. A web service
offers its information in a format that other applications can “understand”, or parse. An application programming interface (API) is a set of routines, data structures, object classes and/or protocols provided by libraries and/or operating system services in order to support the building of applications. All web services are APIs but not all APIs are web services. A web service needs a network, while an API doesn’t need a network for its operation.

Web services use HTTP (or HTTPS) to exchange information with an application, or a “client”, that wants to communicate with the web service. The application sends an HTTP request and the web service then sends an HTTP response (the web service request is sent in a SOAP or REST format; more on this follows).

In the request the required information is passed in the URL itself, as paths in the URL and/or as URL parameters.

For example, the following web service call URL is a request sent to Google Maps and the response will be a map of Syndey, NSW (New South Wales) AU with a specified size and zoom: http://maps.googleapis.com/maps/api/staticmap?center=Sydney,NSW&zoom=14&size=400×400&sensor=false

In addition to the URL, HTTP requests and responses will include information in the header and the body of the message. Request and response “headers” include various types of metadata, such as the browser being used, the content type, language (human, not software), and more. The body includes additional data in the request or response along with a definition of the structure of response messages, which is usually in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format.

http://malidipak.blogspot.in/2013/03/difference-between-api-vs-web-services.html

For all this to work, there’s an interchange mechanism between the back-end (web-service) that does the processing and generation of something useful, and the front-end (which consumes — typically displays — the data), which could be anything: a web, mobile, or desktop application, or another web-service. The only limitation is that the front-end and back-end must “speak” the same “language”.

That’s where SOAP and REST come in. They are structured practices to choose to communicate with the web-service. SOAP, Simple Object Access Protocol, is a specification for exchanging structured information in the implementation of web services in computer networks.

SOAP internally uses XML to send data back and forth. SOAP messages have rigid structure and the response XML then needs to be parsed. WSDL is a specification of what requests can be made, and with which parameters, and what they will return. It is a complete specification of your API.

REST/RESTful is a design concept (the World Wide Web represents the largest implementation of a system
conforming to the REST architectural style) that isn’t as rigid as SOAP. RESTful web-services use standard URIs and methods to make calls to the web service. When you request a URI, it returns the representation of an object, one that you can then perform operations upon (e.g. GET, PUT, POST, DELETE). You are not limited to picking XML to represent data, you can pick anything really (JSON included).

The HTTP query URL definition is all you need to know and use to make calls to a RESTful service. The response can be HTML, comma-delimited data, XML, or a more sophisticated document type (such as a spreadsheet). Some, though, claim that the return of anything but hypermedia-based content is not truly RESTful.

Example: A call to retrieve employment benefits for an employee.

REST

http://humanresources.com/benefits?user=<USER SSID>&type=full time employee

SOAP

123

4

5

6

7

8

9

10

11

12

<SOAP-ENV:Envelope xmlns:SOAPENV=”http://schemas.xmlsoap.org/soap/envelope/“><SOAP-ENV:Header>

some data here…

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<GetBenefits>

<user>123-45-6789</user>

<type>full_time_employee</type>

</GetBenefits>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

http://www.drdobbs.com/web-development/soa-web-services-and-restful-systems/199902676?pgno=3

JSON and XML

JSON and XML are data representations and are ways of serializing data. XML is more flexible and has quite a few standards designed around it, but some feel it is too complex and verbose. JSON is a simpler format which
defines a few basic structures in concise ways, which is easy to use for informal data structures.

http://stackoverflow.com/questions/16626021/json-rest-soap-wsdl-and-soa-how-do-they-all-link-together

API Keys

Accessing an API usually requires some kind of authentication through a proxy using API keys, tokens, usernames/passwords or database URLs. An API key is a code passed by computer programs calling an API. It
identifies the calling program, its developer, or its user to the website. API keys are used to track and control how the API is being used, for example to prevent malicious use or abuse of the API.

Basic auth over HTTPS – Check username/password of the user for every request.

Sessions – Send a session ID with each request; server maintains state. So app sends username/password and server checks for a logged in user on subsequent requests, just like any website does.

API tokens – Mobile app sends username/password and receives a token back, then appends this to subsequent requests. Token stored in DB and checked on each request.

LogiGear Corporation

LogiGear Corporation provides global solutions for software testing, and offers public and corporate software-testing training programs worldwide through LogiGear University. LogiGear is a leader in the integration of test automation, offshore resources and US project management for fast and cost-effective results. Since 1994, LogiGear has worked with hundreds of companies from the Fortune 500 to early-stage startups, creating unique solutions to exactly meet their needs. With facilities in the US and Vietnam, LogiGear helps companies double their test coverage and improve software quality while reducing testing time and cutting costs.

For more information, contact Joe Hughes + 01 650.572.1400

LogiGear Staff
LogiGear Corporation provides global solutions for software testing, and offers public and corporate software testing training programs worldwide through LogiGear University. LogiGear is a leader in the integration of test automation, offshore resources and US project management for fast, cost-effective results. Since 1994, LogiGear has worked with Fortune 500 companies to early-stage start-ups in, creating unique solutions to meet their clients’ needs. With facilities in the US and Viet Nam, LogiGear helps companies double their test coverage and improve software quality while reducing testing time and cutting costs.

The Related Post

Here are some books you might find useful when developing your web services API testing strategy. The Art of Application Performance Testing by Ian Molyneaux — This book was just released and I found it an outstanding conceptual overview of performance testing a web based application. The book does a great job of reviewing the ...
An overview of web service testing solutions for traditional or non-technical testers. Much has been written on the technical execution of API tests, yet there are gaps in the details of what tests to design and how to design them. The articles tend to either get too technical too fast, or are too vague and ...
An API provides much of the functional capabilities in complex software systems. Most customers are accustomed to interacting with a graphical user interface on the computer. But, many do not realize that much of the functionality of a program comes from APIs in the operating system or the program’s dynamic-link libraries (DLL).
APIs are the unsung hero of our connected world We live in an exciting age of intelligence, where progress moves at the speed of imagination. We are connected to the world and one another like never before. API (Application Programming Interface) is the unsung hero of our connected world. Here’s everything you need to know ...
An approach to secure maintainability and scalability for API testing projects   One of the most important tasks in API testing is designing the input data whose quantum could explode due to the combination of a vast number of arguments. An experienced tester will inevitably figure out the advantages of the pairwise method in efficiently ...
Lack of information and access to information isn’t an issue with web services. Web service documentation is widely available. Overview     One of the major persistent complaints from people who test is lack of information and lack of access to information. Luckily this is not the case with web services. If in the rare case with ...
API testing is different from GUI testing, but it doesn’t take long to master. What is an API? API is an acronym for Application Programming Interface. It enables communication and data exchange between two separate software systems. A software system implementing an API contains functions/subroutines which can be executed by another software system.
LogiGear_Magazine–June_2015–All_About_API_Testing
These are the popular authentication methods in TestArchitect Authentication in API testing is usually a complicated subject for both developers and testers since it requires extensive knowledge on various types of security protocols and encryption algorithms.
API: An application programming interface (API) is a set of routines, protocols, and tools for building software applications. An API expresses a software component in terms of its operations, inputs, outputs, and underlying types. An API defines functionalities that are independent of their respective implementations, which allows definitions and implementations to vary without compromising the interface. Source: https://en.wikipedia.org/wiki/Application_programming_interface
Social APIs are omnipresent and create special cases for testing. If you understand API testing, especially web service type APIs, testing social APIs is easy to grasp. The use of social APIs makes them a special case. They are omnipresent and very well understood. What this means is you need to have a good understanding ...
Summary Remember that Agile is not an SDLC. Neither are Scrum and XP for that matter. Instead, these are frameworks for projects; they are built from practices (for example, XP has 12 core practices). Scrum and XP advocates will freely recommend that you pick a few practices to implement, then keep what works and discard ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe