API Call to Specific View
I
IDLX Admin
Currently, when making a GET call to a table, while we can sort or filter, all fields are pulled when we only need a certain subset of fields, especially for our larger tables that have an extraordinary number of fields.
Our current workaround is to create a secondary table with only the fields we need for the API call, which then must be synced with the primary table (i.e., when a new record is created in the primary/master table, that record must also be created in the secondary table, adding an additional layer of table links). Rather than create a secondary table, we'd like to be able to make the call to a specific view of a table so that only specific fields are pulled during the API call.
Happy to further expand if you need more details.
Jon Darbyshire
Great to hear your perspective, IDLX Admin! I have a few more questions for you:
- Can you provide examples of the specific fields you frequently need to access via the API call?
- How often do you find yourself needing to create these secondary tables?
- Are there any specific tables or views that are particularly problematic in terms of the number of fields?
I
IDLX Admin
Hi Jon Darbyshire. Thank you for your follow-up.
- Our main data table has over 200 fields, when each API call usually needs less than 20. The glut of data from all the fields is overwhelming the API systems we are testing with, plus we are now constrained by privacy/security policies at our organization from calling certain fields, so we have to be able to limit their ability to be called into the APIs, else we can't use them at all. Happy to discuss further via email/offline.
- We have just now created this secondary table since the privacy/security policies & permissions granted through our TPRM process are restricting our usage of certain information. Unfortunately, without a way to call specific fields, this means we'll have to do this for our two major data tables with regular updates to ensure the data is "synced"/matches across the tables.
- For our account, the "Class Instances" table in the "Course & Class Database" is our most troublesome/data intensive table at present.