REST configuration- Boolean being sent as text in a POST

ACDC

When sending a Yes/No attribute to a REST endpoint using POST, its being sent as text as opposed to a Boolean format data type. It's being rejected because of this.

How do we get around this problem, is it a bug inside the Awareim REST config ? (The Yes and No setting on the attribute in the configurator appears to relate to a form only) In the image below the red arrow shows the problem. The green arrows show an example of proper format

ACDC

It seems the way around this is to use the string option "Use this string" and make sure the REST request body contains true or false, without the inverted commas

This means you cannot use the "Take from context" option if there exists a boolean attribute in the object

This is a severe limitation in terms of the REST feature, as "Take from context" is powerful when working with complex endpoints

@support. please can you comment on this, could there be a way a boolean be automatically formatted to exclude the inverted commas when using Take from context option

work around.jpg

Jaymer

--> "How do you get around this?"

I'm not sure why you say "Take from context" is so powerful.
I've used this a lot - but I create a JSON_String field/object in the User Table or the new NP in-memory table... building a string to match the endpoint requirements and then I use "Take from context" specifying that table and field that has the JSON.

So if I didn't need the quotes then I'd leave them out on the boolean element and it would work fine.
I also think if he "fixed" this for boolean, the next person might come across an API that needs quotes around ALL elements and now they couldn't use it.

I also think I'd never use "Take from context" using the "None" attribute (as you must be doing) because then all fields from that table would be sent to that API and what about extra fields you don't want to send them? Yes, you can exclude some fields in the service, but that might be a huge list to exclude in some cases - I just don't think I'd ever use "None" as I'm happy building my JSON string into a tmp field.

So thats why I don't think "Take from context" using NONE is that powerful, unless you have a better reason.

ACDC

I'm not sure why you say "Take from context" is so powerful.
I've used this a lot - but I create a JSON_String field/object in the User Table or the new NP in-memory table... building a string to match the endpoint requirements and then I use "Take from context" specifying that table and field that has the JSON.

I do something similar when its a simple layout, but when you POST an Invoice with multiple line items it becomes complex. It gets more complex
when there is a batch operation where multiple invoices with line items exist in a single POST. This is where "Take From Context in my mind is powerful ,if not simpler. There is a reason why this feature exists, but it's broken because booleans are not sent as a boolean.

I would be keen to see your solution for this scenario, I am not sure i can do this

ACDC

I also think I'd never use "Take from context" using the "None" attribute (as you must be doing) because then all fields from that table would be sent to that API and what about extra fields you don't want to send them? Yes, you can exclude some fields in the service, but that might be a huge list to exclude in some cases - I just don't think I'd ever use "None" as I'm happy building my JSON string into a tmp field.

In my case the REST object is stripped down to the min requirement, so if there are attributes that are to be excluded by way of the mapping feature it would be minimal

Also there is a cool feature in the mapping table Attribute Encoding that lets you set the encoding. If Vlad included a Boolean encoding option it would solve the problem both ways

ACDC

but I create a JSON_String field/object in the User Table or the new NP in-memory table... building a string to match the endpoint requirements and then I use "Take from context" specifying that table and field that has the JSON.

So you are building the json string manually ?

If there was a function to create a JSON string, things would be simpler. Also the function could take care of the reference child objects as well.

There is a way to do this via a stored procedure in MySql using JSON_OBJECT, but having an AwareIM function that behaves similarly would be better.