📄️ Designing a custom REST service
To design a REST service properly, you need to analyse the components involved in calling it.
📄️ Defining a custom REST service
This help topic tells you how to define a REST service that is NOT predefined, that is, a REST service that you either generate yourself from SQL or that you program yourself as a custom REST service.
📄️ Defining custom REST methods
The only way for a client to access a REST service is by calling a REST method. A REST method is one precise task that the service offers to its clients. Therefore, when you define a custom REST service, you must also define one or more REST methods. Declare each method on the Methods tab of your custom REST service by providing values for the method properties listed below.
📄️ Defining custom REST input parameters
Input parameters for a custom REST service may be passed in different ways. In the following examples, '154' is the ID of a requested booking:
📄️ Defining custom REST request messages
Some REST methods require request messages, or input messages, to be passed to the server in addition to whatever information may be passed in the various elements of a URL request.
📄️ Defining custom REST response messages
Many REST methods require response messages to be passed to the client in addition to an HTTP status code that is always a default but very limited way of reporting back on how a service call was processed.
📄️ Defining custom REST error handling
By default, when a USoft Rules Engine raises an error this result in an error message that expresses the business rule enforced by the Rules Engine.
📄️ Limiting the number of records returned by a REST service
You can limit the number of records returned by a REST call that returns multiple records. You do this by passing boundary values that define a subset of the records contained in the query result. Only that subset is returned as the REST response. The boundary values are passed as input parameters in the request URL.
📄️ Exposing REST services
Assuming that you have been testing and debugging your REST service(s) using a local URL such as:
📄️ Calling a REST service without committing
It is interesting to be able to run input data against the Rules Engine without committing. This allows you to see what WOULD happen to the data IF they were committed.