Rest API - how to deal with multiple attributes that may be NULL

I am defining a REST API to consume.   It is an interface that sits on top of a database.  The API is pointing to a specific table.   The Request/Response is essentially the fields in the table.   I want to be able to call the API and only assign values to fields that are relevant in that part of application.   I dont want fields that have not been assigned a value to be passed to the API since those fields would be NULLed in the database.  Is there any way to have the REST API function only pass fields in the request header that are not NULL?

Hi Dave,

If the Attributes of the Structures defined by the REST API aren't set to mandatory, they are set to their default value when the consumer of the API doesn't send them. You can't easily know whether or not the default value was explicitly sent or it's default by, well, default. Since the Platform doesn't have the concept of NULL values, you cannot test for them, so you must specify a specific value that means "NULL" and test for that.

Note that in the OutSystems database, NULL values are only used for Identifiers, so your remark that "those fields would be NULLed in the database" is not strictly true.

I am referring to consuming an external rest api, not publishing one.  The api front ends a database table with 200 columns.  Many times that the api is called only a handful of fields need to be set.  since the request structure needs to accommodate all the fields as a pre-defined structure, each call to the api would require that all 200 fields be set each time the api is called.   

Hi Dave,

I completely agreed on Kilian If you want to take any decision when on null values is it default null or consumer is passing null values then consumer need to pass something else in place of  null and you can write your custom code to handle it.



Hi Dave,

I'm a bit confused on your set-up. Is the API a 3rd party (or at least non-OutSystems) API? Then what does that API specify to send for a null value? Some REST APIs require an explicit "null" set, some REST APIs assume non-present values to not exist in the JSON. The former will be difficult to achieve with OutSystems, but the latter is pretty easy: you can specify whether Attributes having their default value are sent to the consumed REST API or not. By default, they are not sent.

Yes, this is a third party API that is used to update a database that is 'owned' by another application.  The data cannot be updated directly - it has to pass thru this API.   The API takes a KeyRecordSet as a request object.   That recordset can contain one or all of the fields to be inserted/updated.   The way the structure gets built in OS for the REST API definition it appears to be too restrictive to work for us.  Im trying to work around it by loading a .net assembly that provides a work around but Integration Studio keeps locking up on me when it determines that the library I'm loading has dependencies.  When the dialog displays to browse to the referenced dll the app locks up and needs to be killed.

Hi Dave,

How did you conclude "the way the structure gets built in OS for the REST API definition it appears to be too restrictive to work for us"? What kind of restrictions do you experience?

I believe I need the ability to dynamically alter the request structure on the fly.   One call may be passing 1 keyrecord pair, the next may need to pass 100 pairs.

Hi Dave,

Like I already said, this needn't be the case. By default, the Platform doesn't send an Attribute (translated to a JSON key/value pair) if the value of the Attribute has the default value for that Attribute. Therefore the only problem you could encounter, functionally, is when you need the full range of possible values for an Attribute (all possible values of an Integer, say) and you need it to be NULL sometimes.

That said, have you researched the possibilities of the On Request / On Response? These will allow you to process the JSON as you see fit, and can be used to further customize your output. Using Integration Studio seems a bit of an overkill, in this situation.