reason why api holds old sets?

[tooomm]

I'm wondering what the reasoning is behind the API containing dropped sets. Currently many sets like BFZ are shown.

I realized when I wanted to use this dynamic badge which uses the api as data source:

https://img.shields.io/badge/dynamic/json.svg?label=What%27s%20in%20Standard%3F&url=https%3A%2F%2Fwhatsinstandard.com%2Fapi%2Fv5%2Fsets.json&query=%24.sets..code&colorB=green

API endpoint used: https://whatsinstandard.com/api/v5/sets.json

When the page is updated to drop sets, why not update the api as well?

[silasary]

Those sets recently rotated out, and depending on what people are using the API for, that may be useful.

[matt-forster]

See https://github.com/glacials/whatsinstandard/issues/52;

v5 took the opinion that the site should support upcoming and recently expired sets for the UI. It is easy to filter the expired sets out if you are consuming, but I understand where you are coming from when using services that are hard to customize.

There have been proposals for supporting multiple endpoints (pre-filtered endpoints), but it is hard to do (read: I think impossible) with a Github Pages hosted API.

[glacials]

What @forstermatth said is correct! To expand:

We are hosted on GitHub Pages because it's free, but the disadvantage is that it only serves static content (the API is static content! I handwrite it :P). Previous API versions would contain exactly Standard sets and I would manually update it at midnight on release days. But I hated doing it and would sometimes forget.

Around the same time we started moving the website to be powered by the API rather than raw HTML (partly to help with this, so I wouldn't need to update two things). So in v5 we started over-including sets, with the advantages that

• it wouldn't need me to do anything at midnight and
• the site could use the over-included sets in past/future sets UIs,

but with the disadvantage that

• consumers would have to filter down to Standard sets themselves (see the API README for a JavaScript function).

I don't super like this solution, especially because it violates the whole name of the website! So in #55 we've been gathering reasons it would be nice to move off GitHub Pages to something with a backend.

Coincidentally I have been toying with backends over the last 3 days or so! So it's probably safe to expect something medium-term.

PS: That's an awesome badge! Did you make that?

[tooomm]

Ok, I see your reasons.

I totally like GitHub pages and it's simplicity. 👍 But can't you prevent a hosted service with backend?

Previous API versions would contain exactly Standard sets and I would manually update it at midnight on release days. But I hated doing it and would sometimes forget.

If you setup travis you could run a script which, depending on date, manages the deletion of rotated sets and then pushes a commit to master (or creates a pr) with the updates. GitHub pages would immediately reflect that. To automate the process, you can setup a daily travis run (cron job) at midnight for example.

The API could still have recently rotated sets or upcoming ones, but with a special status flag like dropped or upcoming.

PS: That's an awesome badge! Did you make that?

I used a great service called https://shields.io/ for that. They have a ton of different static or service dependent badges, but also offer the possibility for a custom dynamic badge like this. ❤️ Check the starting post, I added the url!

[glacials]

Yeah that's very true! I'll look into that as well.