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 more rows.
    For more information, see Post.
  • GET. Read, including filters and sorts.
    For more information, see Get.
  • PUT. Update one or more rows.
    For more information, see PUT.
    For more information, see Delete.
You can test the language examples illustrated in this article in the REST Lab.
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:
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
You can interact with your API by reviewing the following API usage examples:
Application-Oriented Design Approach
A key design goal is to simplify client design, particularly with respect to performance. You can:
  • Supply optimistic locking on update.
  • Have 
    CA Live API Creator
     send the update response that contains the updated rows.
  • 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 Versus Headers
You can facilitate testing by way of browsers by supplying request elements that are typically associated with headers as parameters. For example, you can specify the authentication token as the authorization parameter in the URL.
For more information:
A primary 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": ""