31
Views
8
Comments
Empty fields in REST API vs Null fields
Question

Hello,


We are consuming a REST API which can return certain numeric fields

Let's say for example that the structure is:

{    

  "brand" : "Volvo",    

  "value" : 5500

}


But sometimes, the API can return just:

   "brand" : "Volvo" 

}

Which menas the Value was not found. 

In this case, OutSystems fills the Value attribute with the null, 0. 

The problem is that something can actually have a value of 0, and we need to display that, if that is the case. 


So how to differentiate from the API not returning the field at all, and it returning a value, even if it's the OutSystems Null of 0?


There's unfortunately no direct way. However, OutSystems did describe in the documentation a way to do this (in an article on PATCH), which you can also use here. The tl;dr is that you set a different default value than the default default 0 (e.g. -999999999) , and check for that.

Hi Killian, thanks for your reply.

I went and set the default value to -9999 and yes, that can be tested for and show null, however also I've set some test data to 0 and that also comes back as -9999, which is also set to null. 


Remember we are consuming here, not producing, so I'm not sure PATCH would be the answer? In any case, I've signed the idea to handle Nulls different than zero values. It's been open since 2015. 

https://www.outsystems.com/ideas/213/null-values/


Would the only way be an Advanced OnAfterResponse with C# checking for actual empty json attributes?

that test doesn't really make sense to me, speaking for your (consumer) end of this, if you have defined the default as -9999, an absent value in the json will tranlate to a -9999 but a 0 value in the json will translate to a 0.  

Can you check what comes in the json when you set a test value of 0 ?

I don't have access to the real API to test this, but we have been using a mocked API using OutSystems to test other scenarios, and setting the default on that one to -9999 sort of works. But, again, this is not the behaviour of the real API, it will exclude the attribute from the json, in which case I need our OutSystems consumer to regard this as Null. 

Then, it might include the attribute with a value of 0, which should not be consider Null, but 0 instead.

see attached oap for an example, the producer module in there is just a way to mock the api, it is the consumer it is about

the producer returns this json :

[{"Name":"value not given/known"},{"Name":"Value different from zero","Number":2},{"Name":"A zero is a valid value","Number":0}]

key is setting the default of the structure attribute to -9999999999, and you can see that a zero in the json just stays a zero, and an absent item becomes the default -9999999999

Of course, soon after receiving data from the api, you will probably want to translate that into your own model, where you might for example use an extra boolean to make a distinction between a real zero and an empty/unknown value, instead of that weird -9999999999 value

Dorine

QDR_AbsentNotZeroInAPI.oap

You may want to give my JSONata transformation library a try. More info and getting started here https://medium.com/itnext/transform-json-data-with-jsonata-in-outsystems-ae14acfcf4e4

Taking your result of

{
  "brand": "Volvo"
}
a jsonata transformation of

{
  "brand": brand,
  "hasValue": $exists(value),
  "value": value
}

would return 

{
  "brand": "volvo",
  "hasValue": false
}


Best

Stefan

Sounds like a possible solution. Will evaluate and take it to the team for them to decide adding another piece to this puzzle. Thank you

It might be worth it to create a simple extension that uses newtonsoft JSON to just check if fields are present, if they are empty strings, null etc.


I there is enough need (I would also benefit from this actually), a forge component to do this may be useful.

I believe the JSONListify from ardoJSON might be also suitable, but I am unsure how it works with nested data.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.