The idea is to add (an option to) the relation of an endpoint from the root level to nested tables when using a REST data source. Currently the normal behavior doesn't incorporate this relation. Meaning you end up with the right tables from the endpoint, but have no way to relate these tables. The CDATA connector did bring this relation. Working with Qlik it brings the relation and even the option to choose a key generation strategy. This seems like a gap in the functionality of the TX REST connector. Workarounds are available but costly in resources.
Full description:
When working with REST APIs that have nested endpoints my experience is that a standard setup (without for example table flattening) does not take into account the relation within the nesting hierarchy. In other words, in this way the result is 1 root level table that includes the PK and any number of lower level nested tables that cannot be related back to the main table.
From what I know I either have the option to use a unnecessarily complex solution using dynamic values and query from endpoint tables. This is undesirable because in some cases I have to query the full endpoint two times and run up costs or into rate limits. The other option would be to table flatten every single nested table and carry over the PK from the root level. This is undesirable as in the past couple of cases I was querying endpoints that originally didn't need any table flattening. So something that works as easy as filling in the right parameters turns into a tedious XSLT job.
Adding this functionality to the TX REST connector would help save time and/or reduce the number of necessary API calls. Even more so, it seems to be standard functionality for some of TXs competitors and other players out in the field.
Vilsen,
Luuk Bouman
