I’m working on an interface for a project that builds up databases from our survey results, and among other things need to allow searching for Surveys by partial name, depending on a user’s credentials/team. Since there is no documented fuzzy search, I was initially going to keep a mirror of Survey meta-data in sync and allow users to query that, but it needs to be based on a user’s credentials, since they might not have access to all Surveys, and there doesn’t seem to be a documented way to see what Teams a user is on.
I did notice, however, that it’s possible to use a `LIKE` Filter operator (tested it with SurveyObject), which does exactly what I need, but this isn’t in the documentation. Is this an operator I can safely use, or because it isn’t listed in the documentation, is it not intended for public use, and not guaranteed to always work? Is there an alternate way I can accomplish what I’m looking for?
I also found that operators such as <, >, <=, and >= also work, but are missing from the documentation. Are those missing from the documentation intentionally, and not meant to be used? Or can I safely use them and expect them to work in the future under the same API version?
Hi Jesse, great question!
In general, the SurveyGizmo team very rarely alters the behavior of our REST API, so even though these filter operators are undocumented, I feel they are relatively safe to use. I double checked this with a member of our Engineering team, just to be sure. They reassured me that our team has taken the necessary steps to ensure application security, and so these extra filter operators being available does not present any sort of concern for our team that may warrant them being removed suddenly.
The only reason for pause I can see, is that in the small chance our team did make a change to the API/filtering which caused one of these filter operators to break, it is unlikely to be officially supported (addressed and fixed) by our team. Because of that, I might suggest having a plan B available.
One possible alternate method could be to cache the results of a Survey “GET LIST” API call for each user in lieu of being able to check teams/permissions directly. This would be used in combination with the initial plan you mentioned, keeping a mirror of Survey meta-data. It’s a bit of a roundabout method (and somewhat of a pain to have to implement your own access control), but on the other hand having local copies of this data would lead to better performance than querying the SurveyGizmo API directly for each interaction.
I hope this helps!