Who would benefit? |
Anyone using the /query endpoint through the REST API |
What impact would it make? |
It would improve performance of the query endpoint, as it would be paginated, instead of needing to fetch all ids. It would also ensure that queries always work. Today, if a query has enough entities, it will time out due to Azure Load Balancer limitations. |
How should it work? |
Same as it already does for the portal v2 endpoint: https://portal2-prod1a-euw.productmarketingcloud.com/api/entity/v2 The request body could be pretty much the same as in that endpoint. |
Why is it needed? |
It is needed because queries with many entityids in them take too long to respond. It would be better to have a paginated option, for performance but also to avoid the Azure Load Balancer automatically timing out the query after 4 minutes. |
Additional feedback, background or context:
Seems to me that the https://portal2-prod1a-euw.productmarketingcloud.com/api/entity/v2
works similarly to the /query endpoint we have avaliable through the REST API. Here is a sample of the request body i found:
{
"type": "advsearch",
"parameter": "[{\"type\":\"System\",\"id\":\"EntityType\",\"operator\":\"Equals\",\"value\":\"Brand\",\"relationdirection\":\"\",\"relationtargetentitytypeid\":\"\",\"relationsourceentitytypeid\":\"\",\"datatype\":\"\",\"datetimeInterval\":false,\"queryCriteria\":\"And\"}]",
"pageSize": "100",
"acceptsPagingResponse": "true"
}
With some tweaks it could be made to fit the way the /query endpoint is called, otherwise just introduce a new paginated endpoint.