I'd also really like to see this, It wouldn't take long to set up and could provide for alot of amazing apps that takes advantage of the site.

Dashboard widget please

Just curious, can you write them with login at all ? I wonder how that would work.

One potential problem is how many times this thing will be accessed, I would have to implement some sort of caching, because there's no sense in polling the database when the user is not actually using the site.

PS: JSON no-go? Believe it or not I never use XML, the site, especially the in-the-works area is all JSON. Much lighter and easier to user.

JSON would be great!

I'm not sure quite how the login stuff would work... I think you can call into native code from a Dashboard widget, so that could be doable.  But in general a no-login version would be more useful.

Last edited by mullr (2007 December 10, 3:08 pm)

Glad to hear that we might get the API

About the request limiting, I'd recommend keeping it simple and throttling based on IP, even if that means the Facebook App users are occasionally blocked.

If you're receiving too many requests from Facebook servers then it doesn't matter if it's one or a few users who are causing it; the end result is the same (the server's resources are being exhausted).

Any applications which use the API will need to be designed responsibly such that they make the minimum number of requests required in order to achieve their purpose.

If you start by throttling everyone then maybe at a later date if there's a problem with access you could maintain a short whitelist of IPs which are allowed additional access.

Any updates on an API ファブリス? I'd really like to write a google wave robot to fetch the most popular story for a given kanji.

What I would find useful for an API would be a cached XML or JSON file of information for each kanji, this cache need not be updated too often, perhaps once a week. For example to write an app that fetches the most popular story for a given kanji from the site I'd need at minimum a means of passing a kanji on the url to return a file with all information associated with that kanji, stroke count, frame number, a list of the public stories, stars, reports and author of each story.

I'd expect the easiest way to do it would be to pass an API key via the url and the required API function

returning a page...with information for that kanji parsed into XML or JSON format.

You could give API keys only to people who apply for one, that way it'd be easy to maintain a list of who is using the API and send email updates if you need to make changes which could potentially break applications.

I'll try and think of more use cases....

EDIT: That designing a good API keynote is interesting, another use case:

- Fetching details of a user -

Data sent to API:

API Key
Username

Expected Return Data:

Username, Location, Kanji Count, Total Reviews, Joined, Last Login



I'm sure some other people could chip in some use cases, example data for applications they'd like to write to take advantage of the API.

Last edited by meolox (2009 November 17, 5:03 am)

ファブリス wrote:

But why do you need to get the details of another user from the members list?

I meant the details of the person who would use an application written to interact with the API, not one memeber fetching the details of another.

Last edited by meolox (2009 November 17, 8:49 am)