Such queries could only come from entities probing the API - they are not specifically searching by a parameter of the topic such as a name. All current "authorized" queries use names on all TOB topic searches.
Further, the implementation of that API call may be inefficient. It's possible that all of the topics in the database are retrieved as part of servicing the request. That might, for example, be the reason why the Ontario instance is having more trouble handling the load - that instance has more topics.
To address both the probing issue and the potential inefficiency, please update the API to reject any queries that do not include a "name" parameter. Some things to consider:
don't return an error if the API does not include a name - perhaps return a fixed response that looks like it might be real - even if it is not.
Require that the name parameter include at least 2 letters, as that will prevent the probes from simply adding the name "A" to the API call.
Once this is done, we will need to do a pass through the applications to make sure that there is not a call to the API in regular use that does not include a name attribute.
In the future (not necessarily now) we will likely allow other attributes instead of name - e.g. location or credential type. So what we want is to prevent calls with only page=1874&page_size=100 vs. necessarily requiring name always be included.
We are currently getting queries from unknown IPs that are using the API and making queries such as:
Such queries could only come from entities probing the API - they are not specifically searching by a parameter of the topic such as a name. All current "authorized" queries use names on all TOB topic searches.
Further, the implementation of that API call may be inefficient. It's possible that all of the topics in the database are retrieved as part of servicing the request. That might, for example, be the reason why the Ontario instance is having more trouble handling the load - that instance has more topics.
To address both the probing issue and the potential inefficiency, please update the API to reject any queries that do not include a "name" parameter. Some things to consider:
Once this is done, we will need to do a pass through the applications to make sure that there is not a call to the API in regular use that does not include a name attribute.
In the future (not necessarily now) we will likely allow other attributes instead of name - e.g. location or credential type. So what we want is to prevent calls with only
page=1874&page_size=100vs. necessarily requiring name always be included.