| title | Data Reset | ||
|---|---|---|---|
| description | How mutated data gets restored from the backup twins | ||
| audience |
|
Writes to the API persist to disk, so the data drifts as people experiment. Every API file has a pristine .json.backup twin, and the reset routes restore from it:
GET /resetit/all— restore every APIGET /resetit/:api— restore one API (JSON 404 if the name is unknown)
sequenceDiagram
participant U as Caller
participant S as /resetit/all
participant B as *.json.backup
participant F as *.json
U->>S: GET
S->>B: read each backup
B->>F: copy over live file
Note over F: Next data request reads<br/>the restored file — no restart
The restore is a straight file copy. Because the JSON router reads its file fresh from disk on every request, the reset takes effect immediately — no server restart.
In production the data is reset on a regular cadence (weekly, per the site's disclaimer), and also whenever a new endpoint ships. Want a change to survive resets? Contribute it to the repo so it lands in the backup itself — that is the loop that keeps datasets community-maintained. The reasoning behind this design lives in Why Persistent Writes + Resets.