Language Examples

Language Examples
calac41
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.
  • DELETE
    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.
 
 
Key APIs
The following table includes some of the key APIs:
You can test these APIs in the REST Lab.
APIs
Description
 URL
REST is usually an HTTP-based protocol.
For more information:
 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 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.
Discoverability
A key goal of REST is to make your API discoverable by software. GET requests on base table resources return 
link
 objects:
{
"@metadata": {
"href": "http://acme.com/rest/abl/demo/v1/purchaseorder/1",
"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": "http://acme.com/rest/abl/demo/v1/lineitem?filter=order_number%20%3D%201",
"rel": "children",
"role": "lineitemList",
"type": "http://acme.com/rest/abl/demo/lineitem"
},
{
"href": "http://acme.com/rest/abl/demo/v1/purchaseorder_audit?filter=order_number%20%3D%201",
"rel": "children",
"role": "purchaseorder_auditList",
"type": "http://acme.com/rest/abl/demo/purchaseorder_audit"
}
]
},
The following admin resources are provided:
URL
Description
http://localhost:8080/rest/default/demo/v1/@tables?projectId=1078&auth=vSrmIZxaAJA9StW2XTcy:1
Returns a list of all the tables in an API (here, the evaluation Logic Demo API).
http://localhost:8080/rest/default/demo/v1/
@resources
?projectId=1078&auth=vSrmIZxaAJA9StW2XTcy:1
Returns a list of all the resources in an API.
For more information about admin resources, see System REST endpoints.