Smartbear readyapi что это

Installing ReadyAPI from the Command Line

This page explains how to install ReadyAPI from the command line.

For a typical installation process, see Installation Guide.

To learn how to install VirtServer, see VirtServer Installation.

Before installing

To run ReadyAPI, your computer must meet certain system requirements.

Also, you will need either a ReadyAPI trial license or a commercial Pro license for one or for all ReadyAPI tools (ReadyAPI Test, ReadyAPI Performance, ReadyAPI Virtualization). A Pro license for one of the tools enables basic functionality of the other ones.

Before the first ReadyAPI run, you need to install a license.

For current ReadyAPI users:

If you have an active license of ReadyAPI, you do not need to activate a new license.

VirtServer requires a separate license.

Ubuntu prerequisites

If you install ReadyAPI on the Ubuntu operating system, you should run the following command to avoid an error during the installation:

Download installer

Visit the ReadyAPI Downloads Center and download the ReadyAPI Linux installer of the desired bitness. This package includes JDK, so you can use it on a machine without installed Java. To install ReadyAPI on a headless machine, follow the instructions below.

To download a package on a headless machine, you can use curl or a similar tool:

Installation steps

The following instruction describes the process of installing ReadyAPI on a headless machine.

Prepare the installation file:

There is no need to prepare the installation file on Windows computers.

Make the downloaded file executable:

Mount the ReadyAPI image:

If ReadyAPI is already installed on your computer, you will be asked whether you want to update the current installation or to install the product anew to a different directory.

After the installation is complete, you can run ReadyAPI command-line tools to run tests:

Command-line arguments

Below is a short list of command-line parameters you can use to install ReadyAPI on a headless machine. For the complete list of parameters, see install4j help.

-h, -help, or /?: Displays the list of available command-line arguments.

-manual: Commands the installer to act as if no JRE has been found and displays the dialog where you can choose a JRE or download one if a JRE has been bundled dynamically. If you locate a JRE, it will be used for the installed tool.

You can apply this parameter to Microsoft Windows only.

-c: Executes the installer in the console mode, that is, the interaction with the user is performed in the terminal from which the installer was invoked.

-q: Executes the installer in the unattended mode, that is, there is no interaction with the user and the installation is performed automatically with the default values.

-g: Executes the installer in the GUI mode.

To uninstall ReadyAPI from a headless machine, do the following:

Run the uninstallation script:

Below is a short list of command-line parameters you can use to uninstall ReadyAPI on a headless machine:

-c: Executes the uninstaller in the console mode, that is, the interaction with the user is performed in the terminal from which the installer was invoked.

-q: Executes the uninstaller in the unattended mode, that is, there is no interaction with the user and the uninstallation is performed automatically with the default values.

-h: Displays the list of available command-line arguments.

Run the uninstallation script:

Below is a short list of command-line parameters you can use to uninstall ReadyAPI on a headless machine:

-c: Executes the uninstaller in the console mode, that is, the interaction with the user is performed in the terminal from which the installer was invoked.

-q: Executes the uninstaller in the unattended mode, that is, there is no interaction with the user and the uninstallation is performed automatically with the default values.

-h: Displays the list of available command-line arguments.

Use the following commands to uninstall ReadyAPI:

You can run these commands one by one in the terminal, or combine them in a script file to run in the unattended mode.

Источник

REST Parameter Types

This section describes REST parameter types.

Note: For information on how to configure REST parameters, see the parameter editor description. To learn how to modify the REST request body, see the content editor description.

QUERY is the most common parameter type. It is specified at the end of the URL after the question mark (?). You can see it in the path preview at the top of the REST request editor.

Click the image to enlarge it.

If you simulate submitting HTML forms, use the POST method and add a query to the message body.

Click the image to enlarge it.

If this option is selected, ReadyAPI removes the parameter from the path. After you submit a request, you can see the query in the raw request body.

TEMPLATE or PATH parameters are used to parametrize the request path. They add a placeholder populated with values from the specified options.

Click the image to enlarge it.

The Form editor displays the extra data added for the parameter as a drop-down list.

Click the image to enlarge it.

Known issues

If several resources use the same path with different PATH parameters, ReadyAPI cannot distinguish between them. As a result, you can use only the first resource in the list and cannot switch to another one. This does not affect requests, it affects only the way they are represented in the UI.

HEADER parameters are added as part of the HTTP header of a request.

Click the image to enlarge it.

Here is how the HEADER parameter looks like on the Raw request tab.

Click the image to enlarge it.

MATRIX parameters are added to the resource path before the query string.

Click the image to enlarge it.

Here is how the MATRIX parameter looks like on the Raw request tab.

Click the image to enlarge it.

PLAIN parameters are defined in a request and can be accessed in ReadyAPI, but are omitted when the request is sent.

Click the image to enlarge it.

When a request is sent, its PLAIN parameter is omitted. See the Raw tab below.

Источник

The ReadyAPI Application Programming Interface

ReadyAPI 3.10.1

The following resources contain an overview of available classes and methods:

ReadyAPI core

Describes the classes and methods that relate to the core ReadyAPI functionality:

https://support.smartbear.com/readyapi/apidocs/ready-api-core/

ReadyAPI Test core

Describes the classes and methods that relate to the basic ReadyAPI Test functionality:

https://support.smartbear.com/readyapi/apidocs/soapui/

ReadyAPI Test Pro specific

Describes the classes and methods that relate to the ReadyAPI Test functionality that requires a ReadyAPI Test Pro license:

https://support.smartbear.com/readyapi/apidocs/pro/

ReadyAPI runners

Describes the classes and methods that relate to ReadyAPI command-line runners:

https://support.smartbear.com/readyapi/apidocs/runners/

Many of the classes can be used directly in other programs.

Previous versions

You can get documentation only for ReadyAPI 3.0.0 and later.

To get information related to previous releases, use the appropriate links in the section below:

Or you can manually edit the needed URL in the following way:

Источник

About Virtualization in ReadyAPI

You can use ReadyAPI to create and manage virtual services. This topic provides an overview of the process.

Overview

ReadyAPI has the functionality that allows creating, running, and managing virtual services. These virtual services work similarly to the real API you are creating. You may know virtual services as virtual APIs, virtualized environments, virts or mock services.

Service virtualization helps you quickly create working mocks of a web service and streamline client code development and test creation:

You can start working on client code and tests before developers finish implementing the API operations and before they deploy the API to a server.

Developers and QA engineers can work in parallel.

You can create client code and tests even if some operation (resource) of your API is not available yet.

See Why Creating Virtual Services? to learn more about advantages and disadvantages of service virtualization.

Supported Virtual Services

How Virtualization Works

Virtual services imitate real APIs: they define operations that clients of a real API will call, receive client requests and simulate responses.

With ReadyAPI, you can create virtual services emulating behavior of REST, SOAP, JMS, and TCP APIs as well as JDBC databases. You can see virtual services existing in your project in the Navigator panel under the APIs (Virtual) node:

Click the image to enlarge it.

In the editor on the right, you can see the properties of the virtual service:

Click the image to enlarge it.

REST, SOAP, JMS, TCP, and JDBC services have different properties for customization.

A virtual service emulates a real web service: it runs on some server, receives requests and sends responses to clients. To implement this functionality, you add virtual operations (or actions) to your virtual service. They specify the requests this service will receive. For each request, you can define one or more possible responses. The virtual service will return this or that response depending on test conditions. To determine which response to return, it uses dispatch settings:

Click the image to enlarge it.

You can add operations manually. If your virtual service is based on an OpenAPI, Swagger, WADL, or WSDL specification, ReadyAPI can load the operation list from this specification. One more way to create operations is to record your interaction with some existing API and to extract requests from the recorded traffic.

You can also configure your virtual service to route incoming requests: the service will forward them to some existing web service, receive responses from this API and transfer these responses to the client. This approach is helpful when you need to create a new API based on some existing real API, when you need to create virtual operations from operations of a real web service and in some other cases. For complete information on routing, see Request Routing and Recording.

For complete information on configuring service properties and behavior, see Configuring Virtual Services.

Running Virtual Services, VirtServer

You can run virtual services on the computer, where you have ReadyAPI installed, or on some remote machine.

Local Computer

To run the virtual service on a local computer, you can use either ReadyAPI, or a command-line runner.

Remote Machine

To run the virtual service on a remote machine, you need to install VirtServer there. This is an application for running ReadyAPI virtual services on computers, where ReadyAPI is not installed. You can deploy a virtual service to the VirtServer and run it there from ReadyAPI (see Running Virtual Services on Remote Computers):

Click the image to enlarge it.

ReadyAPI Virtualization Licenses

Basic virtualization functionality is available for users that have any ReadyAPI license (ReadyAPI Test or ReadyAPI Performance). You are able to create, edit and run virtual services of various supported types.

ReadyAPI Virtualization licenses enable enhanced features that make your work easier and more effective: support for data sources, discovering APIs, routing requests, and some others. For complete information on differences, see ReadyAPI Virtualization Licenses.

How Do I Start?

We recommend that you start with the Your First Virtual Service tutorial.

One more tutorial – Data-Driven Virtual Service – describes how to include Excel sheet data into responses.

For information on JDBC database virtual services, see the JDBC Virtual Services tutorial.

Источник