Adding a Caching Layer for the API

[Dominic Barnes]

I've noticed that all the endpoints have the following headers:

Cache-Control: no-cache, no-store

Also, there are no other cache-related headers being implemented. (eg: Etag, Expires) This basically tells me that the API does not want to be cached at all, but I think there are valid use-cases for wanting to use a cache when interacting with Stripe.

In my case, I have a service that sits between our application and Stripe, normalizing and managing billing accounts, it would be great if that long-running process could set up an LRU cache and lighten the load being applied to your servers. (not to mention improve performance on our end since we wouldn't need to go through a Stripe round-trip if the data is cached)

Is there any chance of Stripe defining a cache strategy for the API? I am hesitant to write a cache of my own, since Stripe explicitly states it does not want clients to cache it's responses. (see headers above)

[Matthew Arkin]

Its fairly common for users to cache / locally store parts of the Stripe API. I'd say most users end up storing things like customer, charge, and subscription ids, as well as subscription status. 

Stripe also has a ton of web hooks to alert you when certain items have been updated which would allow you to update your own database / cache.

I suspect a bit of the API not presenting a cache is that cache invalidation becomes a tricky issue for Stripe to handle. When dealing with a billing / payments platform. You want to be sure with some reasonable level of certainty that the data you receive when you make an API call to Stripe is the latest most accurate available. You don't want to charge a customer twice because a cache of a customer object still has the customer marked as past-due. Thus I'd assume the purpose of the headers is to really prevent any sort of networking device between you and Stripe from caching anything causing very difficult to diagnose issues and instead rely on you, the developer, to develop a caching strategy that works best for your unique use case and infrastructure.

Matt 

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at https://groups.google.com/a/lists.stripe.com/group/api-discuss/.

[Dominic Barnes]

That's understandable, I'll consider my options here.

I do wonder if there is value in using the more proactive caching methods such as Etag. This would still require a request to Stripe, but it would be able to inform me as to whether or not the resource in question has actually changed. (as opposed to the more passive forms of caching like Expires where the client waits until that expiration date before it requests the resource again)