As I moved into higher levels, I have progressively been able to notice the problems of the current API. I will explain one common problem and the solutions I’m considering to go around this.
So let’s say you want to enjoy this nice script that allows you to check what reviews are coming next. So you’re thinking, it’s easy, just send a request to the API (well 3 since it’s for radicals, kanji and vocab) then use the mighty JS to go through that and sort by date. So without considering that JS (or any interpreted language for that matter) is terrible performance wise when you want to process 6000 items (it still gets done fast enough on a home computer), the main problem faced by the script now is that WK simply times out when requesting all the levels at once.
Current solution workaround:
1 ask levels by group of 10 or so, more or less dodging the issue by sending more requests (so getting everything ends up taking up to one minute or so sometimes but no more timeout)
2 rewrite the script so the lowest (burned) levels won’t be asked to the API (ugly but saves time and you can get ~30 sec to get your future now)
So I think it is safe to say that neither of these solutions are great on the client side (people don’t like to wait). Server side it isn’t great either. A request of half my vocab (1-25) is 1.1MB of text so I will extrapolate to basically 3MB of text WK has to generate and send you when you reach higher levels (which means bandwidth costs and some processing power).
So there are two “easy” fixes to implement: add a new request on the API to get the information (new reviews coming up). Might save some processing power on the server (I assume it’s faster to sort+select a part of a database than a full dump basically) and a lot of bandwidth (probably around 500 items worse case, so that’s like a quarter of the bandwidth).
https://www.wanikani.com/api/user/yourapikeyhere/study-items/3 <-3 would refer to 3 days for exampleThe second would be a way to request only a part of the information. The current API gives a lot of information on a each character. I believe very few APIs would care about synonyms for example. So maybe appending at the end of the line the information you want. This would probably reduce the size of the request to a quarter of its current size in most cases (plus it would be good for every API out here). Bonus points for putting the two together.
The second solution to get around the timeout because of the bandwidth is to use some compression. ZIP compression nets ~90%, I assume even some stupid research+replace (retarded dictionary compression) would net 50% for basically no cost (the server would use the short 1 character names for everything+1 table as a reference). This also requires some more work client side but with a common compression system there are API who can take care of it and with research and replace it is either trivial or not even needed (people just look for part of the information).
One last option is to move to binary and output the data in its most efficient way. This requires the most work from developers (both from the WK team and third-party) so I’m not expecting it to be much considered. The easiest solutions would probably reduce the load enough so that this solution would look more like overkill.
If you have other ideas I haven’t thought of, please suggest them. The last suggestions are in my opinion not the best since they would bring the most changes to the API but I decided to go along with it and present everything I thought of. Please bring your (constructive) comments and I hope some people from the WK team will see that.
Save our bandwidth, sign the petition! (and as a bonus you save WK’s)