RESTful Arguments

I have a type like the following:

type AppInterface {
    getVersions: function(catalogId: !string, ipType: !string, securityFlags: !json): json js server
}

Using RESTful API like the following, I get the correct result:
http://env/api/1/tenant/tag/AppInterface?action=getVersions&catalogId=JBB&ipType=TOR&securityFlags=%7Bclassification%3A%22U%22%affiliation%3A%22YES%22%7D

However when I redefine the function as:

type AppInterface {
    getVersions: function(catalogId: !string, ipType: !string, securityFlags: !SecurityControls): json js server

}
type SecurityControls {
  classification: string
  affiliation: string
  miscControls: [string]
  disseminationControls: [string]
}

And use the same RESTful API, I get the following error:

<error version="2.0">
<type>
<module>metadata</module>
<name>C3Error</name>
</type>
<id>2852.15</id>
<message>
The function "SecurityControls.fromString" doesn't exist for Target [tenant/tag/SecurityControls?action=fromString]
</message>
<codes>
<k>0</k>
<v>BadActionForTarget</v>
</codes>
</error>

Is this a bug?

Can you post the original API call unencoded?

http://env/api/1/tenant/tag/AppInterface?action=getVersions&catalogId=JBB&ipType=TOR&securityFlags={classification:"U",affiliation:"YES"}

Maybe the type has to mix StringSerializable, and implement a fromString function?

Josh has it right; RESTFUL parameters only work for things that have natural string representations since the URL parameters must be converted from strings to the target values.

Ok that makes sense.

It seems like it was able to go from string to json without issue; would it be unreasonable to expect it could attempt a SecurityControls.make(json) by default in the second case? Would that be a reasonable feature request?

I’m not an expert here, but json is a known parseable format, by calling a native javascript method JSON.parse on a string. So I’d imagine that platform has existing support for that scenario.

In the second case, the platform doesn’t know that you will necessarily be passing a json string. It could potentially check for that, but this would introduce a performance hit.

If it knew the input were a Type then I feel like json string would be a safe assumption no?

It’s not a problem really, it just seems like a lot of extra steps.

JSON inside URLs isn’t really a thing, but anything is possible. We certainly wouldn’t want to guess what the format was because that would be slow and error prone. Also, I think it would be more natural to pass JSON as the body rather than encoded in a query parameter.

If you think there is a missing feature, feel free to submit a ticket. It’s unlikely that we would add any sort of guessing, but if there is a metadata-based way of handling more conversions, we should consider it.