This topic describes the changes made to Ready! API 2.0.
The new Dashboard helps you work with Ready! API more efficiently. You can easily see summary of your recent functional, load, and security tests, analyze test result trends, and start and stop virtual services on local and remote machines. The Dashboard accumulates data from all the project in your current workspace:
The size of the Dashboard storage is limited by the new Dashboard data limit, MB option. If the Dashboard data size exceeds this limit, the oldest data are removed in favor of newer ones.
Easier reference to properties. Ready! API 2.0 includes the new Get Data dialog that helps you insert project, test suite, test case and other property values into parameters of test requests, test cases and test suites easier and faster. Formerly, you had to select properties from the context menu:
In the new dialog, you use the Filter box to find the needed item faster. You can also add custom properties quickly, if needed:
New Step Into script debugger command. The Groovy Script test step has the new Step Into command. You use it to enter a function or another Groovy Script step and continue debugging. See Debugging Groovy Scripts.
Checking endpoints before the test run. Now, before you run a test case, test suite or project, Ready! API checks whether all the “request” steps have endpoints specified. If an endpoint is missing in a request, Ready! API displays a dialog where you set endpoints for one or for all the requests:
Smarter redirect handling. Use the new Follow 302 Redirect with GET property of the REST, SOAP, XML-RPC and JMS requests to simulate “historical” client behavior when processing the 302 Found response code. According to the HTTP specification (RFC 7231), when a client receives this response code from the server, it should use the same verb for subsequent requests. However, for historical reasons, many clients change the verb to GET. Ready! API works according to the HTTP specification and does not change the verb. The new property helps you emulate that “historical” client behavior.
Smarter editing of SOAP request parameters. The Forms view of the request editor automatically activates the Only the first nodes view mode if a request has lots of parameters or if its WSDL definition is large. When this new view mode is on, the Form displays only top-level parameters or the direct children of an expanded parameter. Of course, you can expand nodes to view and edit data at lower levels.
STARTTLS command for sending emails. The Send Mail test step has the new Use STARTTLS command property. It specifies whether the test step should set up a secure connection with the STARTTLS extension for sending an email.
Faster work with databases. The JDBC and Data Connection data sources have the new Fetch Size property that specifies the number of rows to be returned from the database in one fetch. Use this parameter if data fetching takes too much time: one long fetch will be replaced with several smaller and faster fetches.
OAuth2 authorization headers. OAuth 2.0 client credentials can now be sent in request headers. Formerly, you could send credentials only in the request body.
The JSON data source editor has two new buttons – Add and Remove – for creating and deleting columns.
The Clone TestSuite and Clone TestCase dialogs now select the relevant Name field by default. You can start typing a new name right after opening the dialog.
Updated load test reports: we have reorganized report data and added charts for a number of categories.
Composite projects for load tests. Now when you make a test project a composite project, Ready! API saves load tests in separate files. Formerly, in composite projects, all the tests were in the same file.
Improved charts on the Statistics page:
The charts now automatically recalculate the vertical axis scale when you hide or display series.
If the Scale the Y-axis equally setting is ON, the charts automatically change the vertical axis scale on horizontal scrolling. In earlier versions, the scale did not change and you got empty charts when the series values were above the top limit.
The value of the Scale the Y-axis equally setting is saved between sessions now.
Updated UI makes it easier to configure virt properties:
Instead of three controls that set the virt functioning mode in earlier versions, the new UI offers one drop-down list for setting various modes.
Now you can easily change routing options or dispatch settings of multiple operations or delete multiple operations at a time.
The new Search box helps you easily find an operation by its request name, response name or dispatch settings.
New buttons make it easier to clone, rename and delete responses.
New JDBC virts help you simulate databases for your API clients and tests.
Response codes for SOAP responses. Now you can specify status codes for responses of SOAP virts.
Extended list of response codes. The list of response codes in REST and SOAP virt properties now includes unofficial status codes like 420 Method Failure or 509 Bandwidth Limit Exceeded.
Updated transaction log:
A new toolbar command for disabling and enabling logging.
The new Filter box to search for logged requests and responses quickly.
New DuplicateVirtAction command. In the virt editor, it helps you quickly create new virtual operations by cloning existing operations and configuring the clones.
VirtServer Web Interface enables VirtServer administrators to start, stop, and manage virtual services easier, through a visual UI.
VirtServer Docker image. The new preconfigured Docker image helps you instantiate and start using VirtServer in the Docker cloud faster and easier.
VirtServer remembers the last selected item on the Transaction Log page so that you can easily find it if you have to switch between pages or virts.
The VirtServer update process is improved, and the changes to your setting file are now saved during the update process. The location of the file also changed. For more information, see VirtServer Settings File.
The Protection! License Server you use for managing Floating User licenses now supports white lists of users who can access the License Management Console.
Also, you can now dynamically update the white list of users who can use a Floating User license of Ready! API. See Managing Users and Groups.
SoapUI NG Pro licenses now enable Secure Pro features. You do not need an extra Secure Pro license to create and run secure tests in Ready! API 2.0.
Now, if Ready! API has been idle for 12 hours, it automatically releases the Floating User license to enable your teammates to use the product on their computers. This helps you avoid locking the license if some of your colleagues forgot to close Ready! API.
The error messages that may be displayed during license activation have been rephrased and now they help you better understand issues and possible solutions.
To use the product, you now need JRE 220.127.116.11. See System Requirements.
To use a custom report library for storing your templates and reports, you need to specify its directory in Preferences. If you have done this before, the update will overwrite it, and Ready! API will use the default directory (<Ready! API Installation>/bin/reports) instead.
A number of bugs have been fixed.
The Data Generator functionality that was added to the DataSource test step in Ready! API 1.3 has made the DataGen test step obsolete. Starting from version 2.0, we will no longer improve the DataGen test step, and will remove it in one of the future versions of the product. To generate test data, use data sources of the Data Generator type in the DataSource test step.
Ready! API no longer supports Windows XP and early versions of Windows Vista. The earliest supported operating system is Windows Vista Service Pack 2.