I fully understand CF position and am able to change my API handling if needed, but I dont really know what CF are trying to restrict with this clause in the terms.
All of my questions are around using “orange cloud” - we want to protect our API origin(s). However we are very happy with the CF service so aren’t looking to move. Our volumes are currently quite small too, but should grow over time. (And sidenote, the recent changes to dashboard stats is great - we can see some places we can reduce volume). And to be super clear, this is mostly me being paranoid about what the TOS say, being forced to suddenly change would hurt - I want to do the right thing.
Are API calls are excluded per this section or not? There are documents from CF explaining how to setup APIs to be handled behind CF, including how to cache or not cache, and even how zendesk APIs are configured.
I am mainly asking about APIs that include private content, which may or may not be marked with s-maxage headers.
Are you able to explain what drain/load you are trying to avoid on your POPs? I can imagine it is either network bandwidth, request volume or amount of data in your POP cache. In some cases we can bypass CF (unique to us) and secretly connect to our origin(s) (And we have prioritised doing this more, now that we’ve seen this clause)
We’ve been experimenting with Load Balancer to select different origins, although we primary want to drive to Pool(A) and use Pool(B) when A is unavailable. Does this affect anything? I doubt it, but best to ask.
I am guessing that the clause 2.8 is focused on “orange cloud”, if we switch to “grey cloud” and only use DNS services, I presume this clause no longer applies? Should we switch all API calls to a subdomain and use “grey cloud”?
What we do
We deal with live business transactional data. Much of it is secure and private. APIs are used to share data between a single businesses users at different physical locations
We have a number of origins of our own, (not all on CF yet), and some businesses have their own specific origins as well. We are more a geodistributed “edge” type solution, not so much a central “server”.
What we want to achieve
We wish to hide all origin IP addresses. This is our primary reason for using CF
We do like being able to cache API responses in CF -not everything is private and non cacheable, but this isn’t a show stopper.
Not adverse to paying as we grow, but would like to understand where limits might exist. We did enquire about enterprise pricing, but we aren’t there yet in terms of revenue.
Some pseudo examples, in case it helps
a) GET /Api/SystemStatus.json
This is a shared api for all users. Response is public, cached up to 30 minutes
b) GET /Api/SystemStatus/SJFIVJVJHGJ583bfVdfjsh3hth.json
This is a semi private response for a single business, where only that business knows the SJf… part. Response is public, cached for up to 30 minutes
c) GET /Api/SomeSafeData/SJFIVJVJHGJ583bfVdfjsh3hth.json
This is a semi private response with real data, but is considered low risk. Response is public, cached for various times depending on other factors
d) GET /Api/SomePrivateData/SJFIVJVJHGJ583bfVdfjsh3hth.json
This is totally private, and marked private, no-cache, no-store as relevant.
e) POST/PUT /Api/SaveData
Most common operation, sending data to servers. Responses overwhelmingly marked no-cache
NB. Not complaining at all, simply trying to understand what you want us to do and how best to architect solutions.