(Hobby coder here please bear with me)
I tried searching for this but couldn't find a pattern or answer which confused me as this must be a common problem?
I'm writing a simple stock valuation service. My API takes a Stock symbol e.g. "stockdata/GOOG" and returns some calculated statistics. Of course underlying stock data changes frequently and so I need to recompute every now and then. I'm trying to work out how to handle 2 things elegantly
1) User requests stock my service hasn't seen yet: Given there are 10000s of securities it doesn't seem reasonable, or necessary, to go precompute them all. REST wise this confused me though as I understand I should really return 404 if I have no data. The thing is, assuming the stock is valid I'm able to fetch the underlying data and compute my own scores. How should I do this? Currently, I do refresh as a side effect, but that seems nasty. The only other REST method that comes to mind is to ask users to PUT/POST the symbol (no data) and this could trigger me to create/calculate. It just strikes me as odd as all examples I have seen include these methods providing a lot of extra data to present that resource. (All I need is the symbol itself and my service can do the rest. i.e. the GET contains all the information I need to calculate/create the resource)
2) Refreshing state: As data changes all the time I want to recompute but at max once per day as otherwise I hammer the source servers unnecessarily. As with the above how should I trigger refresh? At the moment, my GET checks currency and updates if it's older than a day, but again that doesn't seem RESTy. Should I just return stale data and again leave it to the user to make another call to request an update? Would this be a good use case for patch?
What do you recommend my payloads for these POST/PUT/PATCH should look like?
Thanks, Sev
You are confusing "I have no cached data" with "there is no data". The clients don't really create or update the data, they want to get the latest version. A GET should work just fine. If you as a provider need to do some work in order to return the latest version then fine, it is still a GET.
The same applies to the updates. The users want the current version of the data, so they should use GET. If the data changes then they will get a new version, otherwise they will get an old version. Normal web pages work in the same way, the web server returns the current version and sometimes the data changes.
If you know when you will change the data it is good practice to return a Cache-Control header with a max-age or to use the Expires header or both. That way clients know they can cache the old data, but not forever.