API v5

[glacials]

This is a working todo list for the next API version.

Allow sets that have rotated out to be returned

The API v4 spec allows not-yet-Standard sets to be included in the response, but not once-Standard sets. We should allow both (because we'll need both to power the site with the API) and have consumers filter them out based on enter_date and exit_date. Code snippets for filtering them out would be very helpful to include here.

Move from /\d+/ to /v\d+/ in the path

Just because it feels more common on the web.

[inuyasha82]

I have a proposal: since MTG is available in different languages, we probably can provide the localized version of the json for these languages.

I think that in this case what can be easiily done is to create different api uri like:
/api/5/sets.json or /ap/5/en/sets.json - return the default language english
/api/5/it/sets.json return the italian version, etc.

The easiest thing to do is to create different files one per each language. But the drawback is that then when every block will be released, we must update many files.

Another possible implementation could be that we update the json programmatically depending on the request (drawback: more code)

And like said in #45 probably a reference to the block is needed if we want to programmatically populate the webpage.

[matt-forster]

@inuyasha82 @glacials Continuing the discussion from #45

I think the API should just return all of the sets that we have supported (perhaps even include the addition of all the sets w/ dates as that information is available), and a client application should be smart enough to filter the sets by date. We could also provide endpoints that drill a bit further down and return the filtered sets, allowing clients to not have to manage the dates themselves (very convenient - for them at least).

I'd also like to see endpoint inclusion for the other lists we have presented on the page, banned cards and ban list announcements.

An example of the endpoints (just ideas):

/v5/sets

/v5/sets/upcoming

/v5/sets/dropped

/v5/sets/current

/v5/banned/list

/v5/banned/announcements

Definitely unsure about the structure of the last two. Not sure if the dropped endpoint should just return recently dropped (return limit) or all dropped.

[glacials]

Bans is definitely something we should have in the API, and is a relatively easy add.

I agree with a lot of the rest of your comment, but this is biting off a bit more than I'm willing to chew right now. Remember that there's no possibility for backend code while we're hosted in GitHub pages, so supplying endpoints like GET /v5/sets/current requires one of:

1. Manual updates to these endpoints around midnight on release day (not willing to go back to this model)
2. Automatic updates to these endpoints by some reliable script or something around midnight on release day (at this point I'd rather do no. 3)
3. Move off GitHub pages and have a backend

I think 3 is inevitable, but now isn't the right time to do it. The advantages are there, but aren't yet large enough to be worth the effort and money. Plus I don't really have the free time right now.

However it's probably important that we keep track of the eventual advantages, so I'll make an issue for it (EDIT: #55).

[matt-forster]

@glacials With the addition of Vue, it is definitely possible to do this filtering in the client without a server, from some conversations I've had with my co-workers who work on browser side code.

In fact, this can be done with vanilla javascript and basic XHR.

[matt-forster]

The basic flow would be:

request endpoint file -> xhr to full json object -> filter data -> present on dom

[glacials]

Right, that would work if we had only the /v5/sets endpoint, but your proposal for multiple endpoints like so:

/v5/sets/upcoming

/v5/sets/dropped

/v5/sets/current

is a server-side concern.

[matt-forster]

@glacials I rescind my comment, you are correct. There is no way to make a client side page that emulates a pre-rendered JSON response.

[inuyasha82]

I think that at the moment, the only option available is mantain three different json files, one for each endpoint, that probably will result in something like:
http://whatsinstandard.com/api/5/sets.json -> For current standard (to mantain retrocompatibility)
http://whatsinstandard.com/api/5/dropped.json -> For recently dropped
http://whatsinstandard.com/api/5/upcoming.json -> For the upcoming sets

Then we can investigate how to create a backend infrastructure, and how to host it.