How are xtrf APIs managed?
I'm curious how xtrf determines what does and does not get included in the APIs.
This is sort of of a loaded question since I've recently ran into a couple of missing items that I was/am totally baffled as to why they aren't available.
One is the inability to get meta information about custom fields. Maybe I'm unique in wanting to use the API in this manner, but when constructing front end tools to interface with xtrf, needing, e.g., information about the options from a select control, or data type from an input, etc., for having the ability to dynamically and confidently render a web application that matches what is actually in xtrf would seem very fundamental. But this is missing entirely. Why?
Today while working from a spec that is requesting a web application to frontend our custom client creation process, one of the fields that was requested to set was the "Individual" option in the standard client data, and is in fact one the few options provided in the xtrf's own "add client" dialog in ui. There is no API support to be able to manipulate this option, so we pulled it and now have to instruct users to go set this field manually if they need this post create, not a great experience.
These are just two recent items, but my question, why is there this disconnect between how the xtrf platform works from the UI vs what's available through the API? It would seem obvious to me that if an option is made available through the UI, it should be added to the API as well as part of the same release version of the xtrf platform.
Am I unique here for how I want to use the xtrf API? I would certainly hope not.
It's as if there's a disconnect between the left and right hands here.
Customer support service by UserEcho
You can do nearly everything with the API, but sometimes you have to extend the API:
1. You can create views and put every fields you want to select from API. Then you can get the view data with API
2. You can create macros, which can manipulate the data in XTRF. After you have the macro, you can call it from API and you can pass parameters as well.
If you need more help, contact me.
Hi Viktor,
Thanks for the reply...yes, we've resorted to views on numerous occasions, and "getting our feet wet" with macros, but I'm particularly concerned with the custom field interface.
There appears no view support to define the "items" column so one could get the options of a select control, which implies one would have to write a macro to perform what I would consider a pretty basic query to xtrf.
While it would seem the macro system is a very reliable and handy option, documentation and tools for generating macros is far from ideal so we cringe whenever we're faced with the need to go down that path.
and one more comment about views... they are brittle. We've had a couple occasions recently where someone had turned off a column in a view and unexpectedly broke one of our crucial applications.
I agree with Karl, we have also found that the array of available API endpoints is quite limited compared to what we can do in the UI. It would be nice to have more options there.