Store an API request result?

Beta
#1

Hi @charlie!

From what I understand, Cornerstone API request is triggered on the user’s page load, unless it is already cashed with him, right?

For example, some Google APIs have a free tier of 1000 requests per month.

A single request is able to retrieve an entire list of data we need, containing hundreds of individual items.

If this is triggered by users, 1000 entries get spent quickly. But if the request is made by the website and stored, and then refreshed every hour, it is still within the free 1000 requests per month limit. I imagine it is a similar situation with many other paid APIs.

Then it would be down to looping the JSON stored on the website.

Am I even thinking in the right direction?

Thanks!

2 Likes
#2

From my understanding, yes you are right. That is why the already implemented cache is so important.

The docs say, the cache is only ever delete if:

  • it expires
  • you press the Cornerstone Delete Cache button
  • or a server reset occurs

Expiration is in your control from the external API looper provider settings in Cornerstone. So if you put expiration to never, and the other two events do not occur, your will only ever request your server one time. All other following request will be served from cache.

Charlie told me he will add in information in the response info in the next update, if the response came from cache. That way you can better check if cache works and you do not stress any limits.

3 Likes
#3

Hey guys,

So a user can trigger a new API request if it’s not cached. The cache is not a user session though which I think is the confusion. It’s stored in file based on the values, meaning it’s shared for all user requests if the request is the same. So if you had one cache, 1000s of users could see the page and only trigger the request once.

I added on to the cache parts of the docs. The server reset can be bypassed, it uses the wp temp directory which is usually /tmp/. cs_api_cache_directory is the filter to change just our cache directory.

Yes, In the next release you’ll see is_cache in the API tester info so you can confirm or use it as a condition.

2 Likes
#4

One more question regarding chaching responses @charlie:

Do you store exactly one cache per Looper Provider or multiple caches in regard to the requests?

Lets say in the weather example I add a form field for the city ZIP and add that information as dynamic content to the request. Will there be a cached response for every ZIP, or will the last cached response be overwritten, if the ZIP differs?

In my work I often create response cache files by using the request URI and its parameters as a string and create a hash from it for the file name. That way I can save multiple cache files.

2 Likes
#5

It’s not tied to the Looper Provider, but the values sent to it in regards to the request. How you described the hash creation is exactly how this cache works, the caveat being it’s using md5 for the parameters for now.

If you had a Looper provider that sent different ZIP codes to an API, each individual ZIP would have a single cache and be shared across your entire site.

2 Likes
#6

Roger that :+1:

1 Like