When talking about online services and web services, the following terms must be distinguished because they are easily confused:

• A protocol such as SOAP or XML-RPC describes the valid syntax of API requests and responses
• A architectural style or paradigm (model) such as REST sets the API’s rules and goals but does not necessarily include the correct syntax or details of communication.
• Description languages (descriptive languages) such as WADL (for RESTful web services) or WSDL (for SOAP-based web services) only describe the API in a standardized way. They list all API methods and parameters and the format of requests and responses. The commonly used description language is the XML markup language
• Languages (languages) like GraphQL, JSON, or XML are used to specify the format and syntax of API calls (requests and responses) or API descriptions. That means that an API with a document written in XML can use JSON or simple query strings for actual API calls and not necessarily use XML for that.

API protocol (example): SOAP

• Simple Object Access Protocol or SOAP is a lightweight protocol for users to exchange structured information in a decentralized, decentralized environment ( https: //www.w3 .org / TR / soap12-part1 ) and is the legacy protocol of XML-RPC
• Its API-calls use a variant of the XML markup language for standardized communication.
• SOAP APIs are often described by WSDL
• The concept of packaging data specifying messages includes an envelope containing SOAP Header ( SOAP header ) and SOAP Body (SOAP body).

• Raw request (in text / xml format) for SOAP POST call:

• Once you’ve submitted, the API endpoint will search for people with the first name equal to the name specified inside the <searchstring> tag <searchstring>
• The response is also XML (search results are highlighted). The SOAP response follows the same rules and syntax as required. But instead of an <sam:search> object, it will use <sam: searchResponse> to serve the search.

• If nothing is found, the search results will display an error message:

Description language (example): WADL

• Web Application Description Language is a standard method for describing HTTP-based web applications.
• It has been designed to support application modeling and visualization, code generation, and client and server configuration.
• WADL is based on XML – like SOAP
• The WADL description file includes mandatory root elements such as “application”, “resources” elements and other optional elements:

Another mandatory element is also highlighted: xmlns="http://wadl.dev.java.net/2009/02" Postman allows you to directly import valid WADL and create a new collection from it. This example is taken from the official WADL specifications at https://www.w3.org/Submission/wadl/ .

To import WADL directly need:

1. Click the Import button at the top of the Postman user interface, then open the WADL file from the “Import File” dialog box, or select the “Paste Raw Text” option to copy-paste the code directly.
2. Provided that the WADL syntax is correct, Postman will store all requests from the document into a new collection:

Language (example): JSON

JSON stands for “JavaScript Object Notation” (JavaScript object notation). As the name suggests, each JSON piece of code is actually a valid javascript object. It has many advantages:

• Easily converted to other languages
• Very little cost, a JSON object consists of only a few characters – in addition to the actual payload (data you send to or from the API). Therefore, its readability is also great – once you have learned the fairly simple syntax: { "name": "John", age: 31, "city": "New York" }
• The entire JSON object is enclosed in curly braces
• Separate parameters separated by commas
• Key value pairs are separated by colons as in “key”: “value”
• Text (string) must be enclosed in quotation marks: “New York”
• Many types of data are allowed, for example: strings, numbers, arrays and other JSON objects (enclosed in curly braces). For example:

• There is no need for spacing or padding, but to make it easier to read, use a number of indentation and place each object on its own line. All whitespace that is not part of a value (inside quotes) will usually be cut and removed by the server.

See an example on Postman:

• This is the same request as before (searching for people by name) but this time with JSON:

• The result is also a JSON object: {“Alice Xiang”}
• Make sure to select the appropriate Content-Type for the application: application / json

• When there are no valid results for the given search string, you will get a “not found” response:

Other interesting API testing tools and technologies

You have learned how to test web services with Postman. Of course, there are other tools that you should at least hear about.

• SoapUI : SoapUI is a test application for both REST APIs and SOAP APIs. The basic version is open source and free. Its main use is for designing and performing automated tests, but it can also be used for manual testing.

• GraphQL :
  • Originally designed by and for Facebook, GraphQL quickly became a popular language for web services. This open source technology is hosted by the Linux Nonprofit Foundation
  • This language has its own GraphQL Schema Definition Language. It looks a bit like JSON. But in addition to being a pure format for transmitting data, it also has its own very powerful data query and modification language.

• Swagger UI :
  • Another open source project helps render web service documentation
  • It includes a set of HTML, Javascript and CSS and can automatically generate browseable web documents from any compliant API.

These are the script files used in the requirements in this course: https://github.com/MartinRJ/testtraining

Reference source:

Translated from: https://www.utest.com/academy/tracks/28/courses/common-types-of-apis-and-web-services