Calling class functions
You can call data model class functions defined for the ORDA Data Model and singleton class functions through REST requests, so that you can benefit from the exposed API of the targeted 4D application.
Functions can be called in two ways:
- using POST requests, with data parameters passed in the body of the request.
- using GET requests, with parameters directly passed in the URL.
POST requests provide a better security level because they avoid running sensitive code through an action as simple as clicking on a link. However, GET requests can be more compliant with user experience, allowing to call functions by entering an URL in a browser (note: the developer must ensure no sensitive action is done in such functions).
Function calls
The following ORDA and singleton functions can be called in REST:
Class function | Syntax |
---|---|
datastore class | /rest/$catalog/DataStoreClassFunction |
dataclass class | /rest/\{dataClass\}/DataClassClassFunction |
entitySelection class | /rest/\{dataClass\}/EntitySelectionClassFunction |
/rest/{dataClass}/EntitySelectionClassFunction/$entityset/entitySetNumber | |
/rest/{dataClass}/EntitySelectionClassFunction/$filter | |
/rest/{dataClass}/EntitySelectionClassFunction/$orderby | |
entity class | /rest/{dataClass}(key)/EntityClassFunction/ |
Singleton class | /rest/$singleton/SingletonClass/SingletonClassFunction (see $singleton page) |
/rest/{dataClass}/Function
can be used to call either a dataclass or an entity selection function (/rest/{dataClass}
returns all entities of the DataClass as an entity selection). The function is searched in the entity selection class first. If not found, it is searched in the dataclass. In other words, if a function with the same name is defined in both the DataClass class and the EntitySelection class, the dataclass class function will never be executed.
Functions are simply called on the appropriate ORDA interface or singleton class, without (). Parameters are passed either in the body of the POST request (POST
calls) or in the params
collection in the URL (GET
calls).
For example, if you have defined a getCity()
function in the City dataclass class, you could call it using the following request:
POST request
/rest/City/getCity
with data in the body of the POST request: ["Aguada"]
GET request
/rest/City/getCity?$params='["Aguada"]'
The getCity()
function must have been declared with the onHttpGet
keyword (see Function configuration below).
In 4D language, this call is equivalent to:
$city:=ds.City.getCity("Aguada")
Function configuration
exposed
All functions allowed to be called directly from HTTP REST requests (POST
or GET
) must be declared with the exposed
keyword. For example:
exposed Function getSomeInfo() : 4D.OutgoingMessage
See Exposed vs non-exposed functions section.
onHttpGet
Functions allowed to be called from HTTP GET
requests must also be specifically declared with the onHttpGet
keyword. For example:
//allowing GET requests
exposed onHttpGet Function getSomeInfo() : 4D.OutgoingMessage
Thread-safe
All 4D code called from REST requests must be thread-safe if the project runs in compiled mode, because the REST Server always uses preemptive processes in this case (the Use preemptive process setting value is ignored by the REST Server).
You can restrict calls to specific ORDA functions by configuring appropriate privileges in the roles.json file.
Parameters
You can send parameters to functions defined in ORDA user classes or singletons. On the server side, they will be received in the declared parameters of the class functions.
The following rules apply:
- In functions called through POST requests, parameters must be passed in the body of the POST request.
- In functions called through GET requests, parameters must be passed in the URL with "?$params=" syntax.
- Parameters must be enclosed within a collection (JSON format).
- All scalar data types supported in JSON collections can be passed as parameters.
- Entity and entity selection can be passed as parameters. The parameter list must contain specific attributes used by the REST server to assign data to the corresponding ORDA objects:
__DATACLASS
,__ENTITY
,__ENTITIES
,__DATASET
.
See this example and this example.
Scalar value parameter
Scalar value parameter(s) must simply be enclosed in a collection. All JSON data types are supported in parameters, including JSON pointers. Dates can be passed as strings in ISO 8601 date format (e.g. "2020-08-22T22:00:000Z").
For example, with a dataclass function getCities()
receiving text parameters:
POST request
/rest/City/getCities
Parameters in body: ["Aguada","Paris"]
GET request
/rest/City/getCities?$params='["Aguada","Paris"]'
Entity parameter
Entities passed in parameters are referenced on the server through their key (i.e. __KEY property). If the key parameter is omitted in a request, a new entity is loaded in memory on the server. You can also pass values for any attributes of the entity. These values will automatically be used for the entity handled on the server.
If the request sends modified attribute values for an existing entity on the server, the called ORDA data model function will be automatically executed on the server with modified values. This feature allows you, for example, to check the result of an operation on an entity, after applying all business rules, from the client application. You can then decide to save or not the entity on the server.
Properties | Type | Description |
---|---|---|
Attributes of the entity | mixed | Optional - Values to modify |
__DATACLASS | String | Mandatory - Indicates the Dataclass of the entity |
__ENTITY | Boolean | Mandatory - True to indicate to the server that the parameter is an entity |
__KEY | mixed (same type as the primary key) | Optional - Primary key of the entity |
- If
__KEY
is not provided, a new entity is created on the server with the given attributes. - If
__KEY
is provided, the entity corresponding to__KEY
is loaded on the server with the given attributes
See examples for creating or updating entities with POST requests. See an example of contents downloading using an entity with a GET request.
Related entity parameter
Same properties as for an entity parameter. In addition, the related entity must exist and is referenced by __KEY containing its primary key.
See examples for creating or updating entities with related entities.
Entity selection parameter
The entity selection must have been defined beforehand using $method=entityset.
If the request sends a modified entity selection to the server, the called ORDA data model function will be automatically executed on the server with the modified entity selection.
Properties | Type | Description |
---|---|---|
Attributes of the entity | mixed | Optional - Values to modify |
__DATASET | String | Mandatory - entitySetID (UUID) of the entity selection |
__ENTITIES | Boolean | Mandatory - True to indicate to the server that the parameter is an entity selection |
See example for receiving an entity selection with a POST request. See example for getting a list built upon an entity selection with a GET request.
POST request examples
This database is exposed as a remote datastore on localhost (port 8111):
Using a datastore class function
The US_Cities DataStore
class provides an API:
// DataStore class
Class extends DataStoreImplementation
exposed Function getName() : Text
return "US cities and zip codes manager"
You can then run this request:
POST 127.0.0.1:8111/rest/$catalog/getName