API Information

WaniKani API And Third-Party Apps
1

API Documentation: http://www.wanikani.com/api
Community Github: https://github.com/WaniKani

If you are interested in having your WaniKani API driven project hosted under the Github community repo, let me know. Only stipulation is that it must be open source.

To do list

  • Create API mailing list
  • Create section under Community to highlight community repos

2

Greek.

1 Like
3

Some suggestions:

User Info:

  • House
  • maybe # of Posts

Study Information:
  • Number of Reviews due within 1 hour
  • Number of Reviews due within 1 day

4

Looks like you have everything covered for what I want to use it for :)

Could throw in email address for the user info perhaps?. Might be useful if you wanted to display the user’s Gravatar.

5
Lin said...

Greek.
Geek actually.
6
ChrisKempson said...

Lin said...

Greek.
Geek actually.
Alpha Geek
7
ChrisKempson said...

Looks like you have everything covered for what I want to use it for :)

Could throw in email address for the user info perhaps?. Might be useful if you wanted to display the user's Gravatar.
I'd be against e-mail address being available in a public API.
1 Like
8
Thundyr said...

Study Information:
  • Number of Reviews due within 1 hour
  • Number of Reviews due within 1 day

I would second the 2 above.. knowing that new reviews are due is nice but like some have said it's weird to constantly get the 5 minutes, 20 minutes, then 3 hours situation.. alot of times it would be nice to know that yeah you could review in 5 minutes but then would be on a refresh/review cycle for the next hour.. if you waited an hour you could review all 20 or something at once.. I dunno seems like something like that could be useful for those with limited times available to study.. 
9
Thundyr said...

ChrisKempson said...

Looks like you have everything covered for what I want to use it for :)

Could throw in email address for the user info perhaps?. Might be useful if you wanted to display the user's Gravatar.
I'd be against e-mail address being available in a public API.
This. Reason why I've omitted it. If you want to display the gravatar, the third party app can just ask for the user's email address as an option.
10
Thundyr said...

ChrisKempson said...

Looks like you have everything covered for what I want to use it for :)

Could throw in email address for the user info perhaps?. Might be useful if you wanted to display the user's Gravatar.
I'd be against e-mail address being available in a public API.
Definitely against this.. at the very least this should be defaulted to off and you could have an option to enable if you wanted it.. 
11
Thundyr said...

ChrisKempson said...

Looks like you have everything covered for what I want to use it for :)

Could throw in email address for the user info perhaps?. Might be useful if you wanted to display the user's Gravatar.
I'd be against e-mail address being available in a public API.
As would I
12
Thundyr said...

Some suggestions:

Study Information:
  • Number of Reviews due within 1 hour
  • Number of Reviews due within 1 day

Ok.. I'm open to this. I think the timeframes you have suggested are good. Anyone else has opinions on this?
13

Looks good, and I’m looking forward to it :slight_smile:

Couple of suggestions from my experience.
For reference I’ve done a bit of work on rails APIs before, but I’m no guru.

  • Version the API
    • For instance put the API controllers in app/controllers/api/v1/ and namespace them “class Api::V1::ApiController < ActionController::Base”
    • This means if/when you need to drastically change the API you just make an app/controllers/api/v2/
      • Yes this means duplicating API code, but it stops you breaking anything relying on V1 of the API and you can gracefully move people away from the old versions.
      • It also means you can add fixes/changes to old versions very easily because the code is completely separate.
    • There may be more elegant ways to version it but this is how I handled it for a small API
    • Your API routes would also contain the version e.g. /api/v1/users
  • Use Active Model Serializers https://github.com/josevalim/active_model_serializers
    • This makes using json a lot easier and allows you to expose only the attributes you want to
    • You can also present/decorate the data here, so converting dates into different formats etc
    • If you have user roles/rights you can restrict attributes here too
    • I would namespace these as well since between api versions you might change/remove/add attributes in a serializer. So app/serializers/api/v1/api_serializer.rb would contain “class Api::V1::ApiSerializer < ActiveModel::Serializer”
  • Rate limit the amount of calls that can be done by a key/IP
    • Stops a rogue app eating up resources like a cookie monster
Alternatively rather than doing it all from scratch there are some tools to help like Rabl https://github.com/nesquena/rabl or grape https://github.com/intridea/grape but I’ve not tried either of them before.

Having a quick look over both I think grape might help you out quite a bit and helps to keep the structure RESTful.

14

Regarding the email addresses, you could always return the gravatar hash in the user api call.
It doesn’t expose the email directly and the hashes are public anyway, so nobody can complain.

15

How about Demoted items list for Radicals, Kanji and Vocabulary?
I would want to know the number of items that have been demoted, reading or meaning failure rate and most recent demotion date.

Full disclosure: I’m only interested in this to build a personal drinking game I would run once a week. Just to punish me for my failures.
Either way, I can see a few other options for making my own drinking game with what’s already available to reward my successes.

16

I think we all know what data is relevant :D The rest is secondary. At least if we’re taking about notifications. But if anyone is having plans to do other things, please do so :smiley:

  • Number of (new) lessons available (int)
  • Number of (new) reviews available (int)
  • Time until next review (int, by epoch time)
  • Number of all reviews available 
  • number of all lessons available



17
Thundyr said...

ChrisKempson said...

Lin said...

Greek.
Geek actually.
Alpha Geek
Greek Geek talk.  Are you talking about an APP?  Or an off line something?
18
viet said...

Thundyr said...

Some suggestions:

Study Information:
  • Number of Reviews due within 1 hour
  • Number of Reviews due within 1 day

Ok.. I'm open to this. I think the timeframes you have suggested are good. Anyone else has opinions on this?
I think these are good time periods.
19

Has no one noticed Viet used BURNED???

20
s0kud0 said...

Thundyr said...

Study Information:
  • Number of Reviews due within 1 hour
  • Number of Reviews due within 1 day

I would second the 2 above.. knowing that new reviews are due is nice but like some have said it's weird to constantly get the 5 minutes, 20 minutes, then 3 hours situation.. alot of times it would be nice to know that yeah you could review in 5 minutes but then would be on a refresh/review cycle for the next hour.. if you waited an hour you could review all 20 or something at once.. I dunno seems like something like that could be useful for those with limited times available to study.. 
Here's an idea.
what if the system notifies the user there are reviews waiting for him when the number of  all reviews gets higher than, dunno 30, 40, 50 (depending from the level of the user of course)


So let's say, when there's a review, the app checks if the number of old and new reviews adds together a number specified (like 30, 40, or even 5).

so if a user doesn't get 30 reviews after 6 hours, he doesn't get a notification...