| Trigger Settings
|
| Port
|
By default, the trigger listens on the port 9999. You can change this to use another port that is open.
Important: If the app has multiple triggers that require a port to be specified, specify an unique port number for each trigger. Two triggers in the same app cannot run on the same port.
|
| Configure Using API Specs
|
While creating a REST trigger, you can configure it by uploading an API specification file. You can also upload the specification file after the trigger is created. That is, if the API specification changes, you can merge the changes into an existing app by uploading the specification file again.
To do this, click
True and specify the following. (The default is
False.)
- API Spec: Click
Browse and then select the specification file to be used for configuring the trigger.
- Path: All the paths from the specification file are listed in the drop down. Select a path.
- Method: All the methods relevant to the selected path are listed in the drop down. Select a method.
If
False is selected, you need to specify the
Path and
Method.
|
| Secure Connection
|
By default, it is set to
False. If you set this field to
True, you can create a secure endpoint by providing
Server Key and
CA or Server Certificate.
Server Key - A PEM encoded private key file
CA or Server Certificate - A PEM encoded CA or self-signed server certificate file
|
| Handler Settings
|
| Path
|
The resource path for the operation. By default, the path displayed here is the resource path you had entered when you created the flow. The
Path field is editable. For example, if you want to add a path parameter for a GET operation, you can do so by editing the resource path in the GET flow. If you edit the path in the Path field for a particular REST operation flow, the edited resource path is applicable only to the flow in which it was edited.
Two resource paths with same base path should not contain path parameters at the same location. For example, you cannot have the following paths in the same application:
- /books/{ISBN}/Author/{releaseDate} and
/books/{ISBN}/Author/releaseDate is considered the same from a routing perspective.
In these two paths, since the ISBN value is dynamic, it causes a conflict during path resolution.
- /books/{ISBN}/{releaseDate} and
/books/{ISBN}/Author in the same application is not supported.
Although the two paths appear to be different, when a message comes in, the router mechanism cannot know which path to call (the one with parameter or the one without) since the actual value has been substituted for the paramter.
- Resource path with two different path parameters at the same URL sub-section. For example,
/0.6/api/account/{account}/orderhistory/{orderhistory}/branch/{branch} and
/0.6/api/account/{AccountKey}/Price?ProductList={ProductList}
In these paths even though the paths differ after the base path (/0.6/api/account/), there is a conflict when resolving the
{account} and
{AccountKey} values.
- Multiple REST resources with same base path and same number of path parameters. For example,
/resource/{id} and
/resource/{id1}
-
/messages/{messageid}/comments/{commentid} and
/messages/{messageid}/likes/{likeid}
where the paths differ after
{messageid}.
|
| Method
|
The REST operation which the flow implements, for example GET, PUT, POST, or DELETE. This is a non-editable field since each REST flow implements a single operation.
|
| Output Validation
|
When set to
True, the incoming data (body, headers, and query parameters) is validated against the configured JSON schema. By default, it is set to
False.
|
button and press