API Version Upgraded to 1.50.0
The new API Version allows a, iterative, request chaining mode.
While in the current versions of our API it was already possible to chain requests you can now use iterative and wildcard accessors.
There can not be more then one parameter wildcard per request,
configurations like
$GetBuildingInfo.0.allTags.*.importantTags.*.tag_id
will be invalid and lead to empty results.
Therefore there are multiple Modes and Options. One can either execute a subrequest for all responses of earlier staged requests
↪ Request
{
"0": {
"building_id": 19
},
"1": {
"building_id": 19
},
"2": {
"tag": "$GetBuildingInfo.*.roottag"
}
}
↩ Response
{
"GetBuildingInfo": [
{
< ... >
}
],
"GetBuildingInfo": [
{
< ... >
}
],
"LoadTag": [
{
< ... >
}
],
"LoadTag": [
{
< ... >
}
]
}
and/or apply the wildcard operator to array data on the response of a function like
$<MethodenName>.<Idx> or <*>.<ParameterName>.<Idx> or <*>.<SubparameterName>.
Here is an example for iterating an array response where three different contagt-IDs loaded from a request result in three resonses for LoadTag.
↪ Request
{
"0": {
"building_id": 19
},
"1": {
"tag": "$GetBuildingInfo.0.allTags.*.tag_id"
}
}
↩ Response
{
"GetBuildingInfo": [
{
< ... >
allTags: [
{
tag_id: "..."
},
{
tag_id: "..."
},
{
tag_id: "..."
}
]
}
],
"LoadTag": [
{
< ... >
}
],
"LoadTag": [
{
< ... >
}
],
"LoadTag": [
{
< ... >
}
]
}
Wildcard request chaining is only functional in strict mode and can lead to undefined behavior sending it on non-strict api calls.
You should be very careful with the wildcard feature, since it gets very easy to generate an excessive amount of api load with a single request, especially when using function and parameter wildcards.
Other Changes
- Rooms and POIs now have a spacial interface allowing to load items more efficiently, especially on large guides.
