Hi Joe,

for checking if a request is empty you can add some logic to an OnRequest handler of your REST API. This involves some extra work as a GET request always has an empty request body.

* Add an OnRequest handler to your exposed API

* Add a reference to the GetURLMethod and SetStatusCode of the HttpRequestHandler extension

* Create a User Exception with a name of e.g. ApiException

* Add GetURLMethod to the OnRequest handler flow

* Add an If statement with a condition of GetURLMethod.Method = "POST" and Trim(Request.RequestText) = ""

* If true add a SetStatusCode action with a code of 400. End the true branch with an APIException.

* The false branch should end with a regular End.

This will help you to verify if a request has any value and exits out with a BadRequest if not.

Validating parameters should be done in the actualy endpoint action just like you would validate input parameters of a regular server action. So you define the request payload as a structure with proper "Name in Json" values. OutSystems will deserialize the RequestText (now it should definitly have a value) and you use the deserialized values in your flow. Exit with Status code of 400 and an ApiException just like in the OnRequest handler.

Best

Stefan

Hi Joe,

I did a quick example, so you could easily access the suggestion Stefan presented. (OML here)

I just want to complement with the recommendation of taking into consideration the difference between validations done in the services level and validations done in API level.

So, ask your self, do you want a group of controls/validations to be done in a specific service? Do it inside the service, as Stefan recomended, maybe this approach serves the most cases.

But if you have to implement some kind of validation/controls, that must be applied to all services, consider doing it in the OnRequest, althought it envolves more complexity, promotes maintainability and standard patterns, since you don't need to implement the same controls in each service you add to your API.

So in this example specifically, I whould consider:

• Control Request Body not empty and is POST=> API Level validation 
  *Notice this validation obligate all services in this API to be POST method calls.
• Control if has a specific Header and/or a specific information sent => API Level validation  
• Validation Name is empty or ... => Service Level validation

Regarding validations and exeptions

I recomend you to manage business errors and validations via strutured error output, with different error codes per each validation, personalized messages etc, for example the Name not empty validation you mentioned.

In terms of raising exeptions, I recommend you use it for tecnhical errors, for example the POST method control, or the empty body, or the request header control, as I added in the OML example.

Check the OML, I applied all this concept examples. 

Cheers, have fun coding.

JAS