API V2 Beta Documentation

https://wanikanitoanki.com does not download leeches, as determined by the formula used by @seanblue, @StellaTerra, @hitechbunny et al. However, the Anki card layout might be useful to you.

Thanks. I actually looked into it, but found the cards no to suit my taste. In example, I could only chose to have one field on front and one on back. I. e. Kanji front, onyomi back. I could not have kunyomi if its the preferred reading.

So I wrote my own exporter which now combines the meanings, various readings on the back of the card.

Thanks, that’s a good start for me.

Thanks again wunderbunny, I found the formula by @StellaTerra very helpful. I was able to create some script for the CLI to create a leech.csv ready to import to Anki. I will create another thread for it.

1 Like

Well, it took a bit, but we’ve got an id field on the user payload that delivers a UUID. Enjoy the odds of finding a duplicate (from Wikipedia): “the probability to find a duplicate within 103 trillion version 4 UUIDs is one in a billion”. (Note that we don’t have 103 trillion users.)

4 Likes

And while I’m here talking about changes, we’ve got one that’s going up on Monday: we’re dropping the level field from the assignments payload. That could be a biggy for some folks, so make sure your code still works without that field. The level filter on the assignments endpoint will still work, though.

If you’re wondering why, it has to do with our general move towards more independent and resilient objects in API v2.

Assignments have a subject, which belongs to a level. We want to make that relationship only exist once and make it clear when that relationship changes. By having the level field in the assignments, we have to either maintain that data in the millions of assignments out there (boy, does that suck to update when a subject moves around) and/or cache bust all the assignments delivered through the API when a related record changes.

Dropping it means we update a subject’s level, mark it as updated, bust the cache on that one record, and call it good. For y’all (and us internally), it does mean checking on those subjects periodically, but that has to happen anyway when a subject level changes.

TL:DR; we’re breaking things on Monday. :wink:

2 Likes

I assume that also means that query filter will be gone as well?

Nope, the query filter for level will remain.

Hooray for joins then!

1 Like

Anyone else remember that time @viet thought V2 would be would be out of beta in 2017? :stuck_out_tongue:

The recent changes have been really good though. :grin:

1 Like

I do remember X_X

3 Likes

Awesome, this is great

If this field is removed today it’ll break Tsurukame on iOS :frowning:
I’ve submitted an update to Apple, but as usual they’ve rejected it with no real reason. I’m going to keep trying but I’ve no idea when it’ll be accepted.

I’d appreciate it if you could hold off for a while on deploying this change.
And I know this is still an alpha API, but a bit more warning for breaking changes would be very helpful.

1 Like

We can hold off for a while — let us know how the review process with Apple goes, and we’ll drop the field when an update is out there. :slight_smile:

We’ll also work on more of a heads up for folks — userscripts can respond a bit more quickly than apps that face review processes…

The update was approved yesterday so it should be ok for you to drop the field now! Thanks so much for the extra couple of days!

Apple reviews are so inconsistent - I just resubmitted exactly the same binary and they approved it without any comments. :thinking:

@viet subject_ids param is prone to overflows (on every endpoint that accepts it) and causes error 500 if fed anything outside the int range (less than −32768 or more than 32767).

I can confirm that. Fortunately the largest subject ID is 8813, so a 16-bit ID is probably fine for now. Assignments and reviews, however are in the hundreds of millions. A 32-bit ID is fine for them right now, but I can see it breaking the limit in a few years.

Thanks for bringing this to our attention.

We are going to have to do better error handling on our end to make sure the values passed in subject_ids are within our DB column size limits.

EDIT: Just issued a PR.

A 2 byte column for the subject ID should be fine. I don’t think the app will ever exceed the limitation.

As for assignments and reviews… Assignment IDs are rolling on a 4 byte column. Just checked the the DB and we still have a very long way to go to reach 2_147_483_647.

The reviews are definitely on their way there though… :slight_smile:

1 Like

The size is not the main point. It’s just the application should not crash when client accidentally misses a comma, issuing ?subject_ids=123456789 instead of ?subject_ids=12345,6789.