Getting Started‎ > ‎

Language Examples

The RESTful APIs that result from your resource definitions provide the following "CRUD" services for your resources:

  • POST (insert, one or multiple rows)
  • GET (read, including filters and sorts)
  • PUT (update, one or multiple rows)
You can test your API in the REST Lab. The following diagram illustrates the Execute, REST Lab, Request tab:

For more information:

Key APIs

The following table includes some of the main APIs:

Note: You can test these in the REST Lab.

 APIs Description
 URL REST is usually an HTTP-based protocol.

For more information about REST, see REST Background.
 GET Retrieve resources you defined in API Creator.
 POST Create new resources.
 PUT Update existing resources.
 DELETE Delete existing resources.
 MERGE_INSERT    Insert new row or update if row exists by metadata key.

For more information about MERGE_INSERT, see Merge Insert Metadata Action.
 Summary Information Important summary information returned from POST, PUT, and DELETE, including information to refresh page data and verify rule processing.

For more information about summary information, see Transaction Summary.

API Usage Examples

In addition to the REST Lab, you can interact with your API project by reviewing the following API usage examples:

Application Oriented

A key design goal is to simplify client design, particularly with respect to performance. You can supply optimistic locking on update, you can have API Creator send the update response that contains all the updated rows, and update by sending the resource a set of unrelated rows for updates with no requirement that they be the same type or defined within the same root resource node.

For more information about this application-oriented design approach, see PUT.

Parameters vs. Headers

You can facilitate testing by way of browsers by supplying request elements typically associated with headers as parameters. For example, you can specify the auth token as the authorization parameter in the URL.

For more information:

  • About specifying the auth token in the URI, see Authentication.
  • About the details for the REST parameters, see API Docs.

Sub Resource Reference and Operation

Resources can consist of sub-resources, typically for related data, such as the Lineitems contained in an Order or the Product information for a LineItem. You can operate on a sub-resource, such as updating them, using the API, which you reference with a dot notation in your URL. For example: Customer.Orders.Lineitem.

For more information about how to create sub-resources, see Define Custom REST Resources.


A key goal of REST is to make your API discoverable by software. GET requests on base table resources return link objects:

    "@metadata": {
      "href": "",
      "checksum": "A:d1e88016526ce84e"
    "order_number": 1,
    "amount_total": 35,
    "paid": false,
    "item_count": 2,
    "notes": "This is a small order",
    "customer_name": "Alpha and Sons",
    "salesrep_id": 1,
    "links": [
        "href": "",
        "rel": "children",
        "role": "lineitemList",
        "type": ""
        "href": "",
        "rel": "children",
        "role": "purchaseorder_auditList",
        "type": ""

The following admin resources are provided:

URL Description
http://localhost:8080/rest/default/demo/v1/@tables?projectId=1078&auth=vSrmIZxaAJA9StW2XTcy:1Returns a list of all the tables in a project (here, the eval LogicDemo project).
http://localhost:8080/rest/default/demo/v1/@resources?projectId=1078&auth=vSrmIZxaAJA9StW2XTcy:1  Returns a list of all the resources in an API project.

For more information about admin resources, see System REST endpoints.