ReadyAPI supports testing of services that use the REST protocol to send messages. This topic provides basic information on how ReadyAPI can work with REST messages.
About the REST Protocol
For example, if you need three operations: logging in, logging out and retrieving the current user's account balance, you define a URL like http://sample.test/api/session. A POST request with username and password in the body to this URL will log the user in to the session, and a DELETE request to the same URL will terminate the session and log the user out. A GET action to, for example, the URL http://sample.test/api/session/balance will retrieve the current user's balance.
REST services do not have a single widespread description format, and it is a common practice not to provide any service description. Most often, a description is provided in the OpenAPI, Swagger or WADL format, but there are other options:
OpenAPI and Swagger
OpenAPI and Swagger are two names of the same specification format. OpenAPI is a new name that was introduced in January 2016. Now it typically means the 3rd version of this specification format. Swagger is commonly used for ver. 2 specifications. Nowadays, it also designates a toolset for OpenAPI specifications (OAS).
OpenAPI and Swagger help you describe the structure of your APIs so that machines can read them. The ability of APIs to describe their own structure is the root of all awesomeness in OpenAPI. This enables you to create or use existing tools that automatically build beautiful, interactive API documentation, or tools that automatically generate client libraries for your API in many programming languages. You can even go further and generate server stubs for your API operations. The only thing left is to implement the server logic, and your API will be ready to go live!
Use Swagger Codegen to generate client libraries for your API in more than 40 languages.
Use Swagger UI to generate interactive API documentation that lets your users try out API calls directly in the browser.
Use specifications to connect API-related tools to your API. For example, import your spec to SoapUI or Postman to create automated tests for your API.
Check out other open source and commercial tools that integrate with OpenAPI (Swagger).
OpenAPI and Swagger definitions can be written in YAML or JSON.
WADL uses the XML syntax to describe metadata and available actions. You can also make it as strict as WSDL by defining types, optional parameters and so on. WADL does not have any mechanism to represent data, so data must be sent in a URL. This means that WADL is able to document only about half of the information needed to work with the service. For example, WADL tells you only where the parameter should be in the URL, and that it should be a string. It does not provide a range of valid values. It is possible to add a schema to WADL, so that you can define even complex variable types such as enumerations, however, most services do not do this.
RAML is a human- and machine-readable language for defining REST APIs. RAML was designed to improve the API specification by providing a format that the API provider and API consumers can use as a mutual contract. RAML can, for example, facilitate providing user documentation and source code stubs for client and server implementations. This streamlines and enhances the definition and development of applications that use REST API. RAML uses YAML 1.2 as its underlying format. YAML is a human-readable data format that aligns well with the design goals of this specification. As in YAML, all nodes such as keys, values, and tags are case-sensitive.
You need a PRO license for one of ReadyAPI tools to test REST services. You do not need a ReadyAPI Test Pro license to send REST requests, but it may help you in creating complex functional tests.
There are two test steps you can use to test REST services in ReadyAPI: REST Request and API Connection .
REST Request is a dedicated test step for working with REST services. It offers all the features described below.
API Connection is a protocol-agnostic test step that supports testing REST services. Compared to the original REST Request test step, it offers a simplified and streamlined interface. As the test step is in beta, not all the features described below are available.
What Your Tests Can Do
With ReadyAPI you can modify your REST requests in a variety of ways –
Send requests and receive responses.
View requests and responses in multiple editors that display information as raw text or in special forms used to simplify user input.
Get data from a file and use it in a request.
Add authorization to your request.
Manage request attachments.
View and create request representations.
View and edit request headers.
Get information about SSL certificates used.
Configure other request properties.
Moreover, you can use ReadyAPI tools to make your tests better in a variety of ways:
Create complex tests and emulate most common attacks in ReadyAPI Test to make sure the service is well-protected and responds as expected.
Test your service under heavy load by using ReadyAPI Performance.
Create a virtual copy of your service in ReadyAPI Virtualization and write tests for the functionality that is not finished yet.
ReadyAPI includes a number of sample projects that demonstrate how you can work with REST APIs:
<ReadyAPI Installation Folder>\tutorials\Sample-REST-project.xml
<ReadyAPI Installation Folder>\tutorials\Sample-Authentication-project.xml
<ReadyAPI Installation Folder>\tutorials\Sample-Data-driven-project.xml