Quali Python API, Resource Attributes Values converted to match listed type

Hi Kimo,

Thanks for the suggestion, what is your use case for the return value for an API request, is it intedned for use with third-party automation tools?

You mentioned Integer/Float/Boolean, can you please elaborate what are the use cases for these values?

I really don't understand why my use case here is relevant to the discussion of this feature request.
But here you go.
I added to my service, that talks to a cloud provider, the ability for the simulated switch which is deployed to the SDI (software defined infrastructure) to be optionally attached to a pre-defined physical network. It gets and attribute value on the resource which is a defined as boolean, to mark it as attached (or not) to a predefined physical network. If marked then it looks up the value stored for which network to use.

If the value is true, I need to alter the set up so the simulated switch attaches to that network, thus allowing the devices attached to that switch network access outside of the SDI.

In my code I had to write a custom bit of logic to handle the return of that value when the service queries and item in side the sandbox. Even though I defined the custom attribute as a Boolean type in the TOSCA modeling file, CloudShell returns everything as a string.

Same issue may come up with number values, and and while we're allowed to specify the input type in the Yaml file, we lose that granularity when it gets returned by CloudShell. CloudShell flags it as a "numeric" type and give us a string. May I remind you that in python 2/3 and 2.0/3.0 are not the same result.

Example of the Boolean request:

vs. being able to say:

if session.GetAttributeValue(each.Name, att1_name).Value:
	network_h.build_network_link(n_label=session_GetAttributeValue(
				     each.Name, att2_Name).Value,
				     n_type-'physical')
<br>

Edit: Clarity

@Muli Wienrib

Hi Kimo,

Thank you for the suggestion, your idea seems interesting for enhanced usage of APIs.

However, considering that this can be solved on the client side, coupled with our desire to maintain backward compatibility of the API, we decided that the idea is currently not planned.

We will follow this idea to see if it gains traction and reconsider our decision accordingly.

Cheers

Along the same line the, what is the purpose of being able to in the YAML file to assign an input type, especially with numeric values, only to have that level of control removed? To maintain backward compatibility you could add another field in the return that is 'RawValue' or 'TrueValue' or possible add 2 'YAML Type' & 'YAML Value' for items coming from a Gen2 shell.