The new TX REST source is great: it is still complex, but easier to deal with than CData by far. There are some additions that would make it easier:
When troubleshooting the TimeXtender REST connector, you need to hold on until you can get some data successfully extracted before you can use the file cache feature to see what is coming back and how it is being transformed. Unfortunately, you may not reach this stage and need to guess what the problem is. It may be as simple as having a typo in the URL being called (or Path in the parameters), but you do not have a log of the calls being made.
As an example: I was dealing with an API that has a call structure like this: api.someorg.nl/api/v1/data?$expand=Something&from=2024-01-01T00:00:00.000Z&to=2024-01-31T00:00:00.000Z&<other params> . What I hoped would work was setting expand / to / from / other params up as Query Parameters and using dynamic values for the dates. This did not work because the URL in the Path then became: api.someorg.nl/api/v1/data which returned the metadata for the call without expanding the underlying structure (otherwise it worked fine).
If I had been able to see the actual calls, I would have had an easier time diagnosing this. It is probably useful to have another option that logs the sequence of calls to a separate file so that you can avoid turning on file caching for large calls. If this log also adds the return status of the call, this would allow more fancy setups where an individually failing call in a set can be retried later based on the result.
