Open zhouzi opened 7 years ago
I will write down a README in a few hours.
I will start working to see how I can provide a lastUpdated header within the response. I think this is a great idea. I can insert an UTC datetime field in every documents and set the header with that.
Unfortunately, I wipe the db and re-insert on every updates. That's a quick and dirty fix for the moment but ideally, I don't want to wipe the db and re-insert data that might have not been updated, the lastUpdated header will mislead the clients :( . You will be able to tell if there was an update but you won't be able to tell which resource was updated.
What do you mean about lexical information?
An array of "keywords" saying which cards use what kind of abilities like Resilient
, Shield
, and the likes?
I'm not planning to serve a dump of the data in the format of the API at the moment. It would take away some development time to essentially do something that doesn't benefit the API directly. I consider the dataset to be a neat little file that I actually need to populate the database, it's a plus that people can use it for their own project too. However, providing a dump is something that I will keep in mind.
For the moment, you can avoid the pagination with the ?limit=10000
query but you will still have to query every card resource...twice 🤔 . I will probably flatten the base variation
to aid with that.
Idea for your db workflow: Instead of wiping anything create a brand new versioned bucket and insert the new data there. That way you'll have a bucket for each patch version possibly providing some cool historical data down the road.
PS I'm also interested in contributing. I do web work mostly so I might checkout the website stuff.
@Zhouzi https://github.com/GwentAPI/gwentapi/blob/develop/README.md
@jcurtis Very good idea.
Awesome, thank you very much @Tri125 💪
Regarding the "lastUpdated" field, I was thinking about something really simple like a hard coded date we'd need to change when a patch is shipped. It'd probably make more sense to name it "lastPatchDate" though.
You wouldn't know which cards have changed but since each patch involves quite a lot of changes, it wouldn't be too bad to re-fetch them all if needed.
This information could be added to the root resource: /
To avoid the manual work, Arachas could crawl http://gwentify.com/category/patch-notes/
Not the ideal solution but it'd do the job with a low amount of work. The last patch date is still an useful information and per-resource cache can be added later.
I've create #11 , I'll be using the standard "Last-Updated" http header since there won't be any confusion on what it represent, the format, and how it should be used. Sure, a particular resource might not have been updated as I explained above but if I ever achieve that level of granularity the clients won't have to change anything on their side.
I'm trying to get rid of crawling #12 because it depends on an exterior source and it isn't stable by nature (if the website change layout). I'll still crawl to get artworks since this is about the only way I know how to get them. With that said, I think we can make a good use of the Last-Updated header on gwentify
Thanks for building this, you're opening the doors to community projects 👍
I'm in the process of building a mobile game and will be using the API. I built a JavaScript client to do so:
gwent-api-client
There are a few things that would be neat to add to the API, namely:
Also, I feel like most of the times consumers will want to get all the cards. Instead of paginating through the API, it could be nice to have a JSON dump of the cards. A slightly refined version of the actual dataset.
Anyway, I'd like to give a hand. I could try to figure out how to install the project and get started but it'd be awesome you could just add a small contributing guide. The steps to install the project would be a good start 😄