Most site updates would already be covered by the /subjects endpoint when combined with the If-Modified-Since or Etag header. But yeah… deleted items would currently be missed.
Perhaps the most straight-forward way to indicate deletions would be to add a “status” field:
One thing you can surely do is remove the CA certificate from the certificate chain (the AddTrust one). It’s not needed, because the clients have them in their own trust store. Thats a few KB off the handshake.
This would be implicitly combining results with those from one or more ‘delta events’ tables, assuming the original record was deleted. Maybe including deltas this way could be toggled with a filter since not all clients will be interested in synchronizing.
True. I was thinking deltas would not be included unless the updated_since filter is used. Combine that with your status=active filter and you get back the original updated_since results without deltas.
For my use case I want review statistics with the subject information included. To my mind this is why GraphQL is so popular these days (although there’s no Ruby server side implementation that I know of).
Anyhow, I’m now splicing the subject data into the review_statistics if anyone is interested in that format of data. E.g.:
I’m also working on a cache API, but mine is a userscript framework that runs while the user is on the WK site. Other WK userscripts will be able to access the full cache, which is often a significant portion of the work in writing a userscript.
If I have enough time, I plan to convert all my userscripts to use the framework.
That’s pretty cool, @rfindley. I reckon you’ll satisfy most all use cases that way.
In my case I’m working on an HTML-based screensaver that will cycle through my leaches. To make it a screensaver I’m using a OSX website-as-screensaver tool which doesn’t run userscripts.
The route I’m going makes more sense for sites built on WK data as opposed to WK pages.
I’ll be using the same library for my stats site, so it should be portable. It relies entirely on the WK APIv2.
The main down-side is that the queries and storage will be redundant if used on more than one site. But at least userscripts running on WK won’t have to compete for the per-site storage limit.
You can do this by using the assignment endpoint (preferably with updated_after filter) and filter the response results on the client end by unlocked_at.
It’s not explicitly available, but you can derive it successfully for most vocab by looking at the subcomponents, and just fall back to a single <rt> for the exceptions.
Do you keep data from srs stage changes? Would it be possible to expose some of them through this API? mastered_at, enlightened_at, etc. could be useful for stats and also for fancy timelines in UI.
Could it be that there is a logic bug with updated_after (at least on the /api/v2/review_statistics endpoint)? If I supply the previous data_updated_at field value as updated_after I appear to get review statistics that are updated on or after the given date (or most likely that there are some truncated milliseconds at play here).
For example (won’t be repeatable as soon as I do my new review, but still):
The same issue exists on the subjects and assignments endpoints, so I imagine it affects all endpoints. And yes, adding a second to the timestamp yields an empty collection as expected. So instead, I store the last time I made a request to a particular endpoint and use that instead of max(data_updated_at), as suggested in post 19. (API V2 Beta Documentation - #19 by viet)
