APIM caching inbound policy does not work with API request made from different API Product

Hello Bi Tan,

Following up to see if you have a chance to check my previous response and helped do let me know if you have any further questions on this.

Hi Shireesha Eeraboina, sorry for the late response, I have tested your solution and further refine the solution based on Microsoft Documentation.

I found that your solution isn't working because the vary-by-value operation is not a valid input for the <cache-lookup /> policy.

I had a closer look into the documentation, if we need to use a customCacheKey as you suggested above, we will have to use the <cache-lookup-value /> policy.

I have got the cache working but is still trying to fix an issue of my policy where the API response body returning null value (i.e. there are response header, but the body section is completely empty).

Could you please review my solution below:

<inbound>
<set-variable name="customCacheKey" value="@(context.Request.Url.Path + context.Request.Url.QueryString)" />
        <cache-lookup-value key="@((string)context.Variables["customCacheKey"])" variable-name="cachedResponse" caching-type="internal" />
        <choose>
            <when condition="@((context.Variables.ContainsKey("cachedResponse")) && ((string)context.Variables["cachedResponse"] != null))">
                <return-response>
                    <set-header name="Content-Type" exists-action="override">
                        <value>application/json</value>
                    </set-header>
                    <set-body>@((string)context.Variables["cachedResponse"])</set-body>
                </return-response>
            </when>
        </choose>
</inbound>


<outbound>
        <base />
        <choose>
            <when condition="@(!context.Variables.ContainsKey("cachedResponse"))">
                <set-variable name="responseContent" value="@((string)context.Response.Body.As<string>())" />
                <cache-store-value key="@((string)context.Variables["customCacheKey"])" value="@((string)context.Variables["responseContent"])" duration="600" caching-type="internal" />
            </when>
        </choose>
    </outbound>

Another follow up question about this solution, since the custom cache key will now look up the URI that is being called. Will the cache look up still work if the user submits the query string in different order:

/api/data-api?dataType=Combined&pageNumber=1&Id=201001

vs.

/api/data-api?dataType=Combined&Id=201001&pageNumber=1

Any advice on my findings above would be greatly appreciated. Thanks.

Hi Bi Tan,

Thanks for your details.

You're right — to avoid cache misses due to different subscription keys or API products, using <cache-lookup-value> with a custom cache key is the correct approach.

To avoid cache misses due to different query parameter order, make sure to normalize the query string when building the cache key — extract each parameter individually and rebuild it in a consistent order.

Also, if your response body is returning null, double-check the format and how you're reading it. Use .As<string>() or .As<JObject>() depending on your backend response type.

Please let me know if you have any further queries.

Hello Bi Tan,

Following up to see if you have a chance to check my previous response and helped do let me know if you have any further questions on this.

Hi Shireesha Eeraboina, your latest response does help with the API Product issue, and I have completed another full testing. However, I found that with the usage of custom key policy, the cache key is now sensitive to the order of the query parameters.

e.g.

1. /api/data-api?dataType=Combined&pageNumber=1&Id=123123
2. /api/data-api?dataType=Combined&Id=123123&pageNumber=1

The 2 same requests above now will result in storing 2 cache responses, it won't fetch the response from the cache if I call both API requests consecutively (i.e. cache miss).

Do you know if there is any simple way to address this?

If we add further complexity to the <set-variable name="customCacheKey" value="@(context.Request.Url.Path + context.Request.Url.QueryString)" /> policy, we might able to get it to work regardless of the order of query parameters. However, I'm afraid that it might increase the latency.

Hello Bi Tan,

Just checking in to see if above information was helpful. If you have any further updates on this issue, please feel free to post back.

Hi Shireesha Eeraboina,

Thanks for your suggestion, with the sorted query string, I have tested that the solution is now working as I was hoping. Thank you for your assistance.

In summary, I ended up using <cache-lookup-value> and <cache-store-value> policies + the normalized query parameters to create my custom cache key.

A minor change to your suggestion about normalizing the query string, as I am getting an error (p.Name is not valid) while testing. Below is the solution I used:

Thanks again!

<set-variable name="sortedQuery" 
	value="@{ var queryParams = context.Request.Url.Query 
		.OrderBy(p => p.Key) 
		.Select(p => p.Key + "=" + p.Value); 
		return string.Join("&", queryParams); 
}" /> 
<set-variable name="customCacheKey" value="@($"{context.Request.Url.Path}?{context.Variables["sortedQuery"]}")" />