API/WebService Adaptor

Introduction

This adapter is used to run tests of Web Services: REST, SOAP and others.

Configuration

In the adapter setup we must include all the data that we consider descriptive of the service in general and that apply to all your requests. So that the user does not have to pass them in each message of the diagram. As for example the base url of the service, headers or the authentication method.

Setup Parameters of the REST Adaptor

• EndPoint: base URL to access the service.
• Keep_Session: indicates whether the session should be maintained between requests to the service. If it is checked, the adapter will add the cookies it receives in the responses to the requests it makes.
• IsSecure: indicates if requests to the service were sent over the http or https protocol.
• Service Charset(Opt.): for setting the charset you will use in a sHTTP service (e.g. REST). Words and sentences in text are created from characters. A character encoding provides a key to unlock (ie. crack) the code. Thus, the charset is the encoding information, which is to say the set of mappings between the bytes in the computer and the characters in the character set. Without the key, the data looks like garbage. An example of charset are UTF-8 or UTF-16. It uses Cp1047 by default.
• WADL_File (Opt.): this is a machine-readable XML description of HTTP-based web services (e.g. REST). The aim of the WADL file is to model the resources provided by a service and the relationships between them.
• Headers: allows adding headers to all the requests that are sent to the service.
• Authentication Type: allows selecting the type of authentication that the service requires. Once selected, it allows us to enter the necessary data for the type of authentication selected. No authentication type is used by default.

New Predefined Functions for REST in the Web Adaptor

• deleteRest(resource, headers)
  • Description: it allows the configuration of an HTTP request of type Delete.
  • Resource: indicates the resource within the EndPoint on which the request will be made.
  • Headers: indicates the headers that must be added to the request.
  • Charset: to choose what charset the user wants.
  • Body: indicates que content of the parameter.

• getALLJSONElementValueByTagname(ResponseName, JsonTagName)
  • Description: if the content of the response to a request is JSON, this function allows to retrieve all the values of the element linked to the tagName as an array of values represented with a tastRowValues object. The result is presented with the values separated by the character |, in the field Message / Result / Value.
  • ResponseName: indicate the name which the Http Response was generated.
  • JSonTagName: Tagname expression used to identify the element.

• getALLXMLElementValueByTagName(StepResponse, ElementTag)
  • Description: if the content of the response to a request is XML, this function allows to retrieve all the values of the element linked to the tagName as an array of values represented with a tastRowValues object. Instead of returning only one element (the first), this PF returns a list of all elements.
  • ResponseName: indicate the name which the Http Response was generated.
  • ElementTag: XML´s tag used to identify the element.

• getCookieValue(StepResponse, Cookie)
  • Description: retrieve the value of the indicated cookie.
  • ResponseName: indicate the name which the Http Response was generated.
  • Cookie: indicates Cookie´s name to retrieve.

• getElementsCountByJsonPath(JsonPath, ResponseName): returns the number of elements that have the same JsonPath.
  • JsonPath: the JsonPath to search for.
  • ResponseName: the name under which the HTTP response was generated.

• getElementsCountByTagName(tagName, ResponseName): returns the number of elements that have the same tag name.
  • tagName: the tag name to search for.
  • ResponseName: the name under which the HTTP response was generated.

• getElementsValueByJsonPath(JsonPath, ResponseName): returns all elements that have the same JsonPath.
  • JsonPath: the JsonPath to search.
  • ResponseName: the name under which the HTTP response was generated.

• getHeaderValue(StepResponse, Header)
  • Description: it allows to obtain the value of a received header in an HTTP response.
  • ResponseName: indicate the name which the Http Response was generated.
  • Header: the name of the header from which you want to extract the value.

• getHTMLElementValueByXpath()
  
  • Description: if the content of the response to a request is HTML, this function allows to retrieve a value of an element, using to identify the element an XPath expression.
  • ResponseName: indicate the name which the Http Response was generated.
  • XPathExp: XPath expression used to identify the element.

• getJSONElementValueByJsonPath(StepResponse, JSonPathExp)
  • Description: if the content of the response to a request is JSON, this function allows to retrieve a value of an element used to identify the element the JsonPath. If there are more than one element, returns the first.
  • ResponseName: indicate the name which the Http Response was generated.
  • JSonPathExp: JSonPath expression used to identify the element.

• getJSONElementValueByTagName(StepResponse, TagnameExp)
  • Description: if the content of the response to a request is JSON, this function allows to retrieve a value of an element used to identify the element the TagName. If there are more than one element, returns the first. The result is presented with the values separated by the character |, in the field Message / Result / Value.
  • ResponseName: indicate the name which the Http Response was generated.
  • JSonTagname: Tagname expression used to identify the element.

• getResponseBody:

• getResponseStatus(StepResponse)
  • Description: allows to retrieve response´s Http status code.
  • ResponseName: indicate the name which the Http Response was generated.

• getResponseTime: returns the time taken in milliseconds to receive the response to a request. To identify the response it receives a parameter with the name of the HttpResponse variable from which we want to obtain the information.

• getRest(resource, headers, parameters)
  • Description: it allows to configure an HTTP request of type Get.
  • Resource: indicates the resource within the EndPoint on which the request will be made.
  • Headers: indicates the headers that must be added to the request.
  • Parameters: indicates the parameters that must be added to the URL of the request.
  • Charset: t choose what charset the user wants.

• getXMLElementValueByTagName(StepResponse, ElementTag)
  • Description: if the content of the response to a request is XML, this function allows to retrieve a value of an element using the tag to identify it. If there are more than one element, returns the first.
  • ResponseName: indicate the name which the Http Response was generated.
  • ElementTag: XML´s tag used to identify the element.

• getXMLElementValueByXPath(StepResponse, XPathExp)
  • Description: if the content of the response to a request is XML, this function allows to retrieve a value of an element, using to identify the element an XPath expression. Also, it allows to search values in responses with XHTML content type.
  • ResponseName: indicate the name which the Http Response was generated.
  • XPathExp: XPath expression used to identify the element.

• patchRest(resource, headers, content-type, body)
  • Description: it allows you to configure an HTTP request of type Patch.
  • Resource: indicates the resource within the EndPoint on which the request will be made.
  • Headers: indicates the headers that must be added to the request.
  • Content-type: HTTP standard header that indicates the type of content that is added to the body of the request.
  • Body: content of the Http request.

• postRest(resource, headers, content-type, body)
  • Description: it allows you to configure an HTTP request of type Post.
  • Resource: indicates the resource within the EndPoint on which the request will be made.
  • Headers: indicates the headers that must be added to the request.
  • Content-type: HTTP standard header that indicates the type of content that is added to the body of the request.
  • Body: content of the Http request.

• putRest(resource, headers, content-type, body)
  • Description: allows you to configure an HTTP request of type Put.
  • Resource: indicates the resource within the EndPoint on which the request will be made.
  • Headers: idicates the headers that must be added to the request.
  • Content-type: HTTP standard header that indicates the type of content that is added to the body of the request.
  • Body: content of the Http request.

• responseBodyContainsText(responseName, searchValue)
  • Description: search in the body field of the response (stepResponse), if there is any match with the string of parameter searchValue. True return if affirmative.
  • ResponseName: indicate the name which the Http Response was generated.
  • SearchValue: text to search inside body of response.

• setBasicAuthentication(user, password)
  • Description: it allows to configure the authentication scheme of the requests that are sent to the EndPoint as BasicAuthentication. It overwrites the security setting done in the adapter setup.
  • User: user code used as credential.
  • Password: password to present as credential.

• setBearerTokenAuthentication(token)
  • Description: it allows to configure the authentication scheme of the requests that are send to the endpoint as Bearer Token Authentication Scheme. It overwrites the security setting done in the adapter setup.
  • Token: token´s value that will be presented as credential.

• setDigestAuthentication(user, password, realm, nonce, algorithm, Qoq, NonceCount, ClientNonce, Opaque)
  • Description: it allows to configure the authentication scheme of the requests that are send to the endpoint as Digest Authentication Scheme. It overwrites the security setting done in the adapter setup.
  • User: username used as credential.
  • Password: password to present as credential.
  • Realm: security domain on which security validation must be performed. It is optional, if it is not known, the adapter will try to perform the validation with the data obtained from the response to the challenge.
  • Nonce: nonce returned by the server. It is optional, if it is not known, the adapter will try to perform the validation with the data obtained from the response to the challenge.
  • Algorithm: algorithm used for encryption. It is optional, if it is not known, the adapter will try to perform the validation with the data obtained from the response to the challenge.
  • Qoq: quality of the protection code. It is optional, if it is not known, the adapter will try to perform the validation with the data obtained from the response to the challenge.
  • NonceCount: nonceCount associated with the request. It is optional, if it is not known, the adapter will try to perform the validation with the data obtained from the response to the challenge.
  • ClientNonce: nonce generated by the client. It is optional, if it is not known, the adapter will try to perform the validation with the data obtained from the response to the challenge.
  • Opaque: opaque returned by the server. It is optional, if it is not known, the adapter will try to perform the validation with the data obtain

• setNoneAuthentication()
  • Description: it allows to configure the authentication method of the requests that are sent to the EndPoint as requests without authentication scheme. It overwrites the security setting done in the adapter setup.

Theorical important Concepts related to Web Services

Base URL

It would be the part of the URL that is common to all the requests or requests about that web service, so that the user does not have to enter it in each message that he configures as a request service.

Authentication and authorization data

It is understood that the first interaction that the adapter must perform with the web service will be the authentication and authorization. Currently there are several different standard methods to perform this step and other owners that I would leave to develop on demand, that is, if we find the need.

To emphasize that they are not authentication-authorization methods of the Web Rest services, rather they are associated with the Http protocol, so the development should be oriented to be reused by the Html GUI Adaptor and the Webservices SOAP adapter, if in the future intends to access any Web application that uses any of these methods to authenticate-authorize itself.

Authentication Types

To administer the authentication_type field exists a combo field, which contains a defined authentication that must be enumerated to the user for selection.

 

 

Now comes the enumeration of the authentication types, make a brief description of them and think what parameters we might need.

• No Authorization (None Auth): if the user selects this method, it is not necessary to authenticate to use the service.
• Basic Authorization (Basic Auth): the simplest method only requires the user and password parameters.  https://en.wikipedia.org/wiki/Basic_access_authentication
• Digest Authorization (Digest Auth): this method is a bit stronger because the key is encrypted and the user, in the postman tool when you select this type of authentication requests the following parameters:
  
  
  • User
  • Password
    
    And as optional (default values are used if the user does not provide them) the following:
    
    
  • Realm: security domain against which to authenticate.
  • Algorithm: encryption algorithm. MD5 or MD5-sess.
  • Nonce: code that the server issues in the response when a request is not authorized. It is unique per session and must be included in the following requests.
  • Qop: quality of protection, the possible values are auth (more common) or auth-int (authorization with integrity) I think less supported and used.
  • Nonce Count: number of request made to the server with the same nonce, its obligation depends on the value assigned to Qop.
  • Opaque: it is a value returned by the server in the first unauthorized response, and must be added without modifying all subsequent requests to the server. https://en.wikipedia.org/wiki/Digest_access_authentication

• OAuth 1.0: this method, open Authorization, is more modern to create a first standard related to authentication. OAuth 2.0 is used more but we could find a service that uses it. In Postman the following parameters are requested:
  
  
  • ConsumerKey: a value used by the consumer of the service to identify himself to it.
  • ConsumerSecret: token used by the consumer to validate their ownership of the ConsumerKey.
  • Access Token: access Token.
  • Token Secret: another key to ensure ownership of the access token.
    And as optional parameters (default values if user does not enter):
    
  • Signature Method: the signature method used by the consumer to sign the requests.
  • Timestamp: a timestamp is added to the request.
  • Nonce: random string generated by the client, will be added to all the requests.
  • Realm: indicates the security domain that performs authentication. https://es.wikipedia.org/wiki/OAuth

• OAuth 2.0: the evolution of OAuth 1.0, is the standard most supported by large Internet companies, Google, Facebook, Twitter, etc., not being an expert, I believe it is two-step authentication. Postman only asks for the parameter:
  • Access Token. Access code to the service. But in the option to request an Access Token request data to authenticate against the service that is going to give you the access code for that operation. In addition to these methods other authentication methods appear in Postman such as:
  • Bearer Token. https://swagger.io/docs/specification/authentication/bearer-authentication/
  • AWS Signature. Proprietary method to authenticate in web services in the Amazon cloud platform. http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html
  • Hawk Authentication. New. https://www.drupal.org/project/hawk_auth To implement the different authentication methods in the Front.

Predefined Functions

Below is the list of Predefined Functions for sending requests to the server provided by the adapter, and parameters necessary for its execution. In rest the types of requests correspond with the different methods / verbs contemplated in the HTTP protocol. In principle there will be a function to form a request for each HTTP method. Another requirement is that variables in the diagram should be allowed to compose the different fields of the request.

The existing methods are:

• GET: it is used to read and retrieve the information of a resource on the server. It is probably the easiest to implement since all the most relevant data of the request appear in the URL of the request.
  • httpResponse = get (UrlBase, Resource, List Headers, List Parameters)
  • UrlBase = it would be obtained from the initialization of the adapter.
  • Resource = the resource you want to obtain.
  • List Headers = a list of headers to be added to the request, to be repeated on will write the values given in the adapter's setup.
  • List Parameters = list of parameters to add to the URL of the request in the form of key = value.
  • Example = 
  • As we have said the get requests are used to retrieve the information associated with a resource on the server, the type of the recovered resource is reported in the media-type header, we could retrieve information with Json, Xml, Html, Pdf, Word, Excel format.
  • One of the issues that the function must answer is how to report the evidence of its correct execution, beyond including a message in the application log indicating whether it was executed correctly, we must consider the option of generating a file of evidences with the content of the response.
  • For example suppose a request get to the application whose result in the application itself is the download of a file Pdf or Excel, I believe that when running it in Tast and retrieve the file we should create it in the directory of evidences of the execution.
  • This is the simple screen in which the user includes headers and headers as a single String that will be parsed by the adapter to decompose it, another design could be made in which the user would be adding parameters or headers at will.

• POST: it is used to create a resource on the server, with the information contained in a form, or in a Json, XML or other file. That is, the way in which the data is transmitted in the body of the request may vary, and it is necessary to allow the user to indicate it in some way in order to build the request. It is the header content_type.
  • httpResponse = post (UrlBase, Resource, List Headers, Content Type, Data)
  • In this case, the data could be represented in a Json or XML file that the user should either be able to upload to the application or cut and paste it in some editor, as in the case of the Queries or the Javascript code.
  • In the case of using forms, the types X-WWW-FORM-URLENCODED or FORM-DATA the requirements change and the user should provide us with a series of parameters in the form of a key value.
  • As well as in some cases attach files to the request.
  • Example = http://www.mkyong.com/java/how-to-send-http-request-getpost-in-java/ With two different libraries.

• PUT: it is used to update the information related to a resource on the server. Similar to post in requirements.
  • httpResponse = put (“UrlBase, Resource, List Headers, Content Type, Data)

• DELETE: it is used to delete a resource on the server.
  • httpResponse = delete (“UrlBase, Bank, User, Account, balance”)

• HEAD: similar to GET, but the response does not contain the body, the data, only contains the header.

The problem of session Maintenance

The problem of the validation of the Response

The problem of session Maintenance

REST Mapping Assistant

Prerequisites

Opening the REST Mapping Assistant