Docs‎ > ‎Debugging‎ > ‎


As shown here, select REST Lab in the Logic Designer to test retrieval and update logic without writing a program, including provisions for REST Parameters.  

You can operate on these End Points:
  • Base Tables - this gives you an instant way of retrieving and loading data, for example. 

  • View Tables

  • Stored procedures

  • Resources - you can also test explicitly defined Resources
  1. Select End Point (Table, View, Procedure, Resource)
  2. Select Named Resource [optional Version]
  4. URL used to send to the API Server
  5. Optional Args dialog
  6. Auth Token used to execute resource
Request Body - used to hold PUT/POST/DELETE JSON
Response Body - display response from REST execution

REST Lab Screens

The sub-sections below outlines the various screens provided in the Rest Lab.

Request Body

Select your Resource or Table, and click Send Request as shown here.  You will then see the result as shown in the following sections.

In rare cases, you may wish to override the optimistic locking check for PUT requests.  Do so with care.

After updates, you can explore the Transaction Summary (Tx Summary) and the Rule Summary to investigate the results of your requests' logic.


You can view the JSON response in the lower pane after you click GET, POST, PUT, DELETE.

You can then copy selected JSON and copy to the Request area, change it (such as the change to qtyOrdered above), then click Post or Put to issue an update.  (Select Post or Put using the drop down box on the green SEND button)

Transaction Summary Tab

REST Lab tab TxSummary shown below will display the last POST/PUT/DELETE rule transaction summary- in Summary Information, you can also see the effects on related rows, and the logic execution flow.

Rule Summary Tab

In REST Lab Rule Summary shown below will highlight the rule execution for a given PUT/POST or DELETE.  The nested or indentation shows the levels of recursive firing of the rules.


The REST Lab is very useful in managing and testing your data.  In the examples below, we use Base Tables.  We could also use Resources, but Base Tables are available as soon as you create your project and connect to a database, so they are often the simplest.

The REST Lab enables you to rapidly test your API without writing programs, for example:
  • Security: you can examine the Security-augmented SQL as shown here

  • Updates - you can post/put data as shown in the sub-sections below

  • Logic: you can issue updates and examine the Log as shown for Allocation.  It is often easiest to:
    1. Select a Table (so you don't need to define a Resource)
    2. Perform a Get
    3. Copy a portion of the resultant JSON
    4. Return to the Request pane, paste the JSON, update it as desired, select Put, and Send Request.  To debug your logic:
      • Use the Log, or
      • Select the debug option 

Reading Data - GET

You can retrieve data with filters or sorts using GET, such as

REST retrieval requests commonly specify filtering and ordering for the top-most Resource.  Since these are coded into the URL, proper escape sequences must be employed (we often use this tool).  


The Args selection will allow you to add system sorts and filters or user named sorts and filters to your GET query.

Selecting the Args will allow different types of Named or Named Filters and Named Sorts
The suffix "_uc" will uppercase a specific system filter (e.g. equals_uc).

Here is a GET using a simple filter:
For testing only - you can use filter and order instead of structured filters.  Use API Properties/Settings to disable using filters and orders.

Here is a GET request for customers with name < 'Shari', ordered by name (descending):


Filters are sql WHERE clauses, so you can use familiar functions such as LIKE:

Other SQL rules apply as well, such as interchanging quotes for double-quotes, checking for null (e.g., filter=name+IS+NOT+NULL), and so forth.

Explore the other parameters for GET here (see API Information,  ResourceList and ResourceSingle).

The Get option simplifies filter testing by providing automatic HTTP escapes:

Loading Data - POST

In addition to the example shown on the REST Lab, you can process batches of JSON.  For example, this JSON in the API: Demo project:

    "name": "New Cust 1",
    "balance": 0,
    "credit_limit": 900
    "name": "New Cust 2",
    "balance": 0,
    "credit_limit": 5000

can be loaded using POST.

Altering Data - PUT

A good way to test your Rules is to issue updates from the REST Lab:
  1. Get the data from a table, view, procedure or resource, as described above
  2. In Response, select the rows you want to change
  3. Paste them into the Request area
    • Note this will include the @metadata tag, required for optimistic locking
  4. Make the changes
  5. Click Put

Subpages (1): Working with binary data