Retrieve rows from an endpoint, a table, a resource that you define explicitly in API Creator, or a custom endpoint using the GET verb.
The results depends on the API user's roles.
In this article:
Verify the Prerequisite
Before you can use the GET verb, you have verified that you have an authentication token.
Connect to your API
REST/JSON invocation is a standard practice, available in virtually every modern language. Use the code samples that are in API Creator to connect to your API, such as the following JavaScript code sample:
To view these code samples, with your API open, in the Tools section, click 
API Docs
, and then click 
Code samples
The following are key concepts of retrieval, including detailed programming information about retrieval.
You can issue HTTP-based retrieval requests against a resources using a URL, for example:
Database Abstraction
In most cases, you retrieve data through explicitly defined resources. The resource/attribute names are distinct from the underlying database column names. You can devise more appropriate names, and insulate your client applications from subsequent changes in the database structure.
Rich Objects: Client Simplification and Network Latency
Conventional database operations that retrieve "flat" results, that is, every row has the same columns and columns are always single-valued, does not always serve well the needs of client applications which require data of multiple types (Customer, Order) in a hierarchy. You can define these resources by defining a resource explicitly in API Creator.
For example, the following code snippet shows that the 
 attribute for a customer is a list of orders: 
[ {
"@metadata" : {
"checksum" : "595d608c67056bf308fd36e48a3d4916"
"name" : "Alpha and Sons",
"Balance" : 85, "CreditLimit" : 900,
" : [ {
"checksum" : "7aa03a46f8a6d40755c22d233b32eddf"
"order_number" : 1,
"TotalAmount" : 35,
Retrieve an Object by Primary Key
You can retrieve a single JSON object by appending its primary key to the resource using the following syntax:<data source prefix:resource name>/<primary key>
For example: and Sons
Layer7 Live API Creator
 applies security to all REST retrieval (GET) requests, including resources that pre-date security specifications. Column-instance security means that a column might be available for some rows, but not others.  
Layer7 Live API Creator
 delivers secured columns as null values. So that clients can distinguish these from actual stored null values, 
Layer7 Live API Creator
 updates the 
 link to designate secured columns.
 For more information:
Specify Filters and Sorts
GET requests commonly specify filtering and ordering for the top-most resource. Since these are part of the URL, you must encode the special characters that are part of your URL. You can get the encoded version of the URL using a tool such as the URL encode/decode tool.
For more information about the URL encode/decode tool, see the URL Encode/Decode tool.
The following image shows a SQL WHERE clause (
As Defined
) in the REST Lab:
This filter is more susceptible to injection.
The following URL is a GET using a simple filter:
The following URL 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 OR and LIKE, for example:
Other SQL rules apply as well, such as interchanging quotes for double-quotes, checking for null (for example, 
), and so forth.
If you are calling stored procedures, you can pass in their arguments, not as a filter expression, but as an argument like this:
If you are using a database with quoted identifiers, in the filtering section of the REST Lab, click 
Add Filter
, and then specify the following in filter field:
"name" = 'Alpha and Sons'
Best practice:
 Use a named filter (as a URL argument):
?sysfilter(name: 'Alpha and Sons')
For more information about named filters, see Structured Filters.
Specify Filters to Subresources
You can also specify fully-qualified filters on subresources that filter them, like this on the resource 
Subresource filters affect retrieval of only the designated resource, that is, they do not affect parent joins. For example, a resource of Customers and Orders with this filter does not filter Customers. You can achieve these effects with more elaborate examples.
You can specify more elaborate subresource filters. For example, the following filter retrieves only those customers with orders in excess of 1000:
Specifying subresource filters can affect performance.
=exists ( select * from <schema>.PurchaseOrder co where amount_total>1000 and co.customer_name = name)
The following image shows the filter in the URL field in the REST Lab:
Specify Filters using Column Names
Specify filters using non-aliased column names in 
 clauses and not column aliases. This arises out of the SQL considerations.
For more information about the SQL considerations, see the MySQL website.
For example, the following SQL query is valid:
select name as TheName from Customer where name = 'Acme'
The following SQL query is not valid:
select name as TheName from Customer where TheName = 'Acme'
For more explanations about why you cannot specify column aliases in 
 clause, see the Beyond Relational site.
Test GET in the REST Lab
You can test GET using the REST Lab. You can eliminate the need for HTTP escape characters and simplify testing by selecting the 
 checkbox. Supply arguments in the URL and use single quotes.
The following image shows the 
 checkbox in the REST Lab:
Define Linked Resources
In large applications, it might be desirable to load all the information required for a page in one transmission, but also provide buttons that navigate to other pages to "zoom in" to detail information. For example, a Customer page might show orders and line items with product name and price, with an option to see detail product information.
This scenario is supported by defining linked resources. These are returned as link objects containing href URIs to retrieve related resources, as illustrated in the following code:
"lineitem_id" : 11,
"ProductNumber" : 2,
"OrderNumber" : 6,
"Quantity" : 2,
"Price" : 25,
"Amount" : 50,
"Product" : {
"@metadata" : {
"href" : "http://localhost:8080/APICreator/rest/demo1/Product/2",
"checksum" : "A:48902e67a13d55bea694c7ff99ff35bb",
"links" : [ {
"href" : "http://localhost:8080/APICreator/rest/demo1/ProductDetailLink?filter%3Dproduct_number%3D2",
"rel" : "children",
"title" : "ProductInfo",
"type" : "ProductDetailLink"
"product_number" : 2,
"Name" : "Shovel",
"Price" : 25
jsonObject Response Format
You can set the default format for the response for the entire API. You can override this setting on a per-request basis by adding an HTTP header to the request. The header's name is 
 and then enter the value for the desired format. The jsonObject response format specifies a different format for GET responses that includes the data in an object. For example:
"success": true,
"data": [
"@metadata": {
"href": "http://localhost:8080/APICreator/rest/el-local/demo/v1/Customers/Alpha%20and%20Sons",
"checksum": "A:e86aea2e0a4e74bf"
"Name": "Alpha and Sons",
"Balance": 4484,
"CreditLimit": 9000,
"Orders": {
"data": [
"@metadata": {
"href": "http://localhost:8080/APICreator/rest/el-local/demo/v1/Customers.Orders/1057",
"checksum": "A:c55ae9a21faa5a45"
"OrderNumber": 1057,
"TotalAmount": 0,
The jsonObject response format also puts the 
 links out of the arrays of objects. For example:
"success": true,
"next_batch": "http://localhost:8080/APICreator/rest/el-local/demo/v1/demo:LineItem?pagesize=5&offset=15",
"previous_batch": "http://localhost:8080/APICreator/rest/el-local/demo/v1/demo:LineItem?pagesize=5&offset=5",
"data": [
"@metadata": {
"href": "http://localhost:8080/APICreator/rest/el-local/demo/v1/demo:LineItem/11",
"checksum": "A:2e3d8cb0bff42763",
"lineitem_id": 11,
"product_number": 2,
"order_number": 6,