[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-08-18 UTC。"],[[["\u003cp\u003eCaching temporarily stores data for faster retrieval, reduces processing time, and lightens the load on backend servers.\u003c/p\u003e\n"],["\u003cp\u003eApigee offers caching capabilities through PopulateCache, LookupCache, InvalidateCache, and ResponseCache policies for improved API performance.\u003c/p\u003e\n"],["\u003cp\u003eThe Response Cache policy in Apigee caches responses from backend servers to prevent repeated requests, improving API performance and reducing network bandwidth.\u003c/p\u003e\n"],["\u003cp\u003eCaching error responses with the Response Cache policy can lead to users receiving error messages even after the underlying issue has been resolved, which is generally not recommended.\u003c/p\u003e\n"],["\u003cp\u003eIt is a best practice to set the \u003ccode\u003e<ExcludeErrorResponse>\u003c/code\u003e element to \u003ccode\u003etrue\u003c/code\u003e in the ResponseCache policy to avoid caching error responses, and Apigee specifically advises against caching 5xx error responses.\u003c/p\u003e\n"]]],[],null,["*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/caching-error) documentation.*\n\nCaching is a process of storing data temporarily in a storage area called cache for future\nreference. Caching data brings significant performance benefits because it:\n\n- Allows faster retrieval of data\n- Reduces processing time by avoiding regeneration of data again and again\n- Prevents API requests from hitting the backend servers and thereby reduces the overhead on the backend servers\n- Allows better utilization of system/application resources\n- Improves the response times of APIs\n\nWhenever we have to frequently access some data that doesn't change too often, we highly\nrecommend to use a cache to store this data.\n\nApigee provides the ability to store data in a cache at runtime for persistence and faster\nretrieval. The caching feature is made available through the [PopulateCache policy](/apigee/docs/api-platform/reference/policies/populate-cache-policy),\n[LookupCache policy](/apigee/docs/api-platform/reference/policies/lookup-cache-policy), [InvalidateCache policy](/apigee/docs/api-platform/reference/policies/invalidate-cache-policy), and [ResponseCache policy](/apigee/docs/api-platform/reference/policies/response-cache-policy).\n\nIn this section, let's look at Response Cache policy. The Response Cache policy in Apigee\nplatform allows you to cache the responses from backend servers. If the client applications\nmake requests to the same backend resource repeatedly and the resource gets updated\nperiodically, then we can cache these responses using this policy. The Response Cache policy\nhelps in returning the cached responses and consequently avoids forwarding the requests\nto the backend servers unnecessarily.\n\nThe Response Cache policy:\n\n- Reduces the number of requests reaching the backend\n- Reduces network bandwidth\n- Improves API performance and response times\n\nAntipattern\n\nThe [ResponseCache policy](/apigee/docs/api-platform/reference/policies/response-cache-policy) lets you cache HTTP responses with any possible Status code,\nby default. This means that both success and error responses can be cached.\n\nHere's a sample Response Cache policy with default configuration: \n\n```gdscript\n\u003c!-- /antipatterns/examples/1-1.xml --\u003e\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u003e\n\u003cResponseCache async=\"false\" continueOnError=\"false\" enabled=\"true\" name=\"TargetServerResponseCache\"\u003e\n \u003cDisplayName\u003eTargetServer ResponseCache\u003c/DisplayName\u003e\n \u003cCacheKey\u003e\n \u003cKey Fragment ref=\"request.uri\" /\u003e\u003c/CacheKey\u003e\n \u003cScope\u003eExclusive\u003c/Scope\u003e\n \u003cExpirySettings\u003e\n \u003cTimeoutInSec ref=\"flow.variable.here\"\u003e600\u003c/TimeoutInSec\u003e\n \u003c/ExpirySettings\u003e\n \u003cCacheResource\u003etargetCache\u003c/CacheResource\u003e\n\u003c/ResponseCache\u003e\n```\n\nThe Response Cache policy caches error responses in its default\nconfiguration. However, it is not advisable to cache error responses without\nconsiderable thought on the adverse implications because:\n\n- [Scenario 1](#scenario1): Failures occur for a temporary, unknown period and we may continue to send error responses due to caching even after the problem has been fixed\n\n **OR**\n- [Scenario 2](#scenario2): Failures will be observed for a fixed period of time, then we will have to modify the code to avoid caching responses once the problem is fixed\n\nLet's explain this by taking these two scenarios in more detail.\n\nScenario 1: Temporary backend/resource failure\n\nConsider that the failure in the backend server is because of one of the following reasons:\n\n- A temporary network glitch\n- The backend server is extremely busy and unable to respond to the requests for a temporary period\n- The requested backend resource may be removed/unavailable for a temporary period of time\n- The backend server is responding slow due to high processing time for a temporary period, etc\n\nIn all these cases, the failures could occur for a unknown time period and then we may start\ngetting successful responses. If we cache the error responses, then we may continue to send\nerror responses to the users even though the problem with the backend server has been fixed.\n\nScenario 2: Protracted or fixed backend/resource failure\n\nConsider that we know the failure in the backend is for a fixed period of time. For instance,\nyou are aware that either:\n\n- A specific backend resource will be unavailable for 1 hour **OR**\n\n- The backend server is removed/unavailable for 24 hours due to a sudden site failure, scaling issues, maintenance, upgrade, etc.\n\nWith this information, we can set the cache expiration time appropriately in the Response Cache\npolicy so that we don't cache the error responses for a longer time. However, once the\nbackend server/resource is available again, we will have to modify the policy to avoid caching\nerror responses. This is because if there is a temporary/one off failure from the backend\nserver, we will cache the response and we will end up with the problem explained in scenario 1 above.\n\nImpact\n\n- Caching error responses can cause error responses to be sent even after the problem has been resolved in the backend server\n- Users may spend a lot of effort troubleshooting the cause of an issue without knowing that it is caused by caching the error responses from the backend server\n\nBest practice\n\n- Don't store the error responses in the response cache. Ensure that the `\u003cExcludeErrorResponse\u003e` element is set to `true` in the [ResponseCache policy](/apigee/docs/api-platform/reference/policies/response-cache-policy) to prevent error responses from being cached as shown in the below code snippet. With this configuration only the responses for the default success codes 200 to 205 (unless the success codes are modified) will be cached. \n\n ```gdscript\n \u003c!-- /antipatterns/examples/1-2.xml --\u003e\n \u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u003e\n \u003cResponseCache async=\"false\" continueOnError=\"false\" enabled=\"true\" name=\"TargetServerResponseCache\"\u003e\n \u003cDisplayName\u003eTargetServerResponseCache\u003c/DisplayName\u003e\n \u003cCacheKey\u003e\n \u003cKeyFragment ref=\"request.uri\" /\u003e\n \u003c/CacheKey\u003e\n \u003cScope\u003eExclusive\u003c/Scope\u003e\n \u003cExpirySettings\u003e\n \u003cTimeoutinSec ref=\"flow.variable.here\"\u003e600\u003c/TimeoutinSec\u003e\n \u003c/ExpirySettings\u003e\n \u003cCacheResource\u003etargetCache\u003c/CacheResource\u003e\n \u003cExcludeErrorResponse\u003etrue\u003c/ExcludeErrorResponse\u003e\n \u003c/ResponseCache\u003e\n ```\n- If you have the requirement to cache the error responses for some specific reason, then you can determine the maximum/exact duration of time for which the failure will be observed (if possible):\n - Set the Expiration time appropriately to ensure that you don't cache the error responses longer than the time for which the failure can be seen.\n - Use the ResponseCache policy to cache the error responses without the `\u003cExcludeErrorResponse\u003e` element.\n\n Do this *only if you are absolutely sure that the backend server failure is not for a\n brief/temporary period*.\n- Apigee does not recommend caching 5xx responses from backend servers.\n\n| NOTEAfter the failure has been fixed, remove/disable the [ResponseCache policy](/apigee/docs/api-platform/reference/policies/response-cache-policy). Otherwise, the error responses for temporary backend server failures may get cached."]]
