Note also: The github event feed appears to be public, so people have often had bots listen automatically for keys for exploitation. I recall reading (earlier this year?) about how someone had some $Ludicrous AWS bills because of this.
> After two weeks, if actions have been made on the deck then we throw it away.
I presume this should say if NO actions have been made. Sending the card image URL is wasteful considering the address is deterministic. Also, you will want to implement a true random shuffle if you want anybody to use this API seriously (see https://www.random.org/).
True Random Shuffle is an interesting concept. Is shuffling a deck of cards truly random? What if I tried to simulate the event of shuffling. e.g. split the deck (list) into two, then choose 1-5 cards at a time from each half of the deck to rejoin the cards back into one. Then repeat.
There is a good discussion here (https://news.ycombinator.com/item?id=7207851) about random shuffling in the context of online poker. The specifics of your shuffle algorithm don't really matter if your numbers aren't truly random.
Neat! The semi-persistant decks are a nice feature and will no doubt prove useful for any form of long-lasting multiplayer games. My query though, why send the image url by default? it seems like an overhead that can be done without. How random are the results likely to be?
I think this is a good idea. There can be a change in the structure of where things are hosted (think moving the images to a CDN as traffic increases) which won't require a new client to find the optimized images.
This is a probably a bad reason, but the reason why I include the image URL is because I thought it would be the easiest way to portray the information. It was easier just to add it into the json response than it was to write it into the doc sheet that currently images could be available by concatenating the suit with the value and making that the file name of the image which could be found at deckofcardsapi.com/static/image/FILENAME.png... Although Farris has a good point.