Language Examples

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.
    For more information about POST, see Post.
  • GET. Read, including filters and sorts.
    For more information about GET, see Get.
  • PUT. Update one or multiple rows.
    For more information about PUT, see PUT.
    For more information about DELETE, see Delete.
You can test your API in the REST Lab. The following diagram illustrates testing your API on the Execute, REST Lab, Request tab:
REST Lab.png  
For more information about how to test your API in the REST Lab, see Test your API Using the REST Lab.
In this article:
Key APIs
The following table includes some of the key APIs:
You can test these APIs in the REST Lab.
REST is usually an HTTP-based protocol.
For more information:
Retrieve resources you defined in API Creator.
Create new resources.
Update existing resources.
Delete existing resources.
Insert new row or update if row exists by metadata key.
For more information about MERGE_INSERT, see MERGE_INSERT Metadata Action Tag.
 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 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: 
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 
"@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:
Returns a list of all the tables in an API (here, the evaluation Logic Demo API).
Returns a list of all the resources in an API.
For more information about admin resources, see System REST endpoints.