MetaFilter APIs for client access April 24, 2010 4:19 AM   Subscribe

Are there any APIs or best practices for programmatic access to MetaFilter? In particular, for things like logging in/out, fetching users' messages, sending messages, making posts and comments, favoriting comments, &c. Ways of fetching content in a more fine-grained way than the RSS feeds would also be nice.

I'm thinking of writing a MeFi client for a certain mobile platform, which would work better at keeping track of MeFi threads on the go than accessing the site in the mobile browser. As such, my client will need to log into MetaFilter, fetch posts and new comments, and allow the user to post comments, send messages, favorite comments, &c. I'd need to:

- log in as the user (either with a straight password or using some kind of OAuth/Flickr-style privilege-based authentication)
- get lists of new posts/comments (the RSS feed will work, though something for only fetching comments/posts after a given time would be even better)
- post comments to threads
- favorite/unfavorite comments/posts
- fetch the user's inbox contents/lists of messages
- send private messages

This could be done by pretending to be the user agent, but that is a bit inelegant and could change if the design/layout change. If there are CGI-style forms whose specifications are set in stone, that could be usable, though. In an ideal world, I'd like to see a RESTful API using JSON and/or XML, though.
posted by acb to Feature Requests at 4:19 AM (14 comments total) 4 users marked this as a favorite

You might have to create a RESTful API using JSON and/or XML that pretends to be the user agent. Then you'd have to share it. You would receive many hugs.
posted by xorry at 6:04 AM on April 24, 2010 [1 favorite]


Sounds good, but I'd suggest waiting until after the first reply to request the £3,670.00 transfer fee.
posted by gman at 6:13 AM on April 24, 2010


No, we don't have any APIs and no programmatic access beyond RSS feeds and the infodump. You've laid out a good wish list here though, and it's something we've talked about adding. It's also a large project for a small crew.

I know from past conversations with mathowie and crew that we would not be happy with an app with "MetaFilter" in the title, or an app that asked people for their MeFi username/password. So until we have a secure alternate method of authentication, we'd rather not see something like this in the wild. We want user data to stay as secure as possible more than fun new ways to interact at MeFi.
posted by pb (staff) at 7:14 AM on April 24, 2010


Now that facebook is on board OAuth 2.0 sounds like it might be turning into the de facto standard for this kind of thing.
posted by Skorgu at 7:18 AM on April 24, 2010 [1 favorite]


You might want to be careful with this, as it could be considered "republishing" metafilter content without permission of the individual posters, and that would bring the unholy wrath of the cabal down upon you.
posted by blue_beetle at 8:26 AM on April 24, 2010 [1 favorite]


[tinc]
posted by sciurus at 9:25 AM on April 24, 2010


What I'm thinking of would not involve republishing on the web, but rather a handset-based app which authenticates, fetches structured data and presents it to the user on the handset, also allowing them to interact with the site, in a similar way to the way that Facebook's iPhone app works.

My ideal wishlist would be:

- authentication: OAuth
- API type: RESTful URLs, with JSON and XML user-selectable; i.e., with URLs like:

GET http://api.metafilter.com/thread/123456/fpp -> { text: "This is the FPP text.", author: {id:1234, name="Example Username"}, }
GET http://api.metafilter.com/thread/123456/comments?after=876543 -> { comments: [ {text:"."}, author:{...}}, {} ] }
POST http://api.metafilter.com/thread/123456/comment <- { text: "This is a new comment." } -> {id: comment_id}

and similar methods for the mailbox and such.
posted by acb at 9:37 AM on April 24, 2010


(Those URLs should perhaps have a ?format=json at the end of them.)
posted by acb at 9:39 AM on April 24, 2010


++
posted by floam at 2:00 PM on April 24, 2010


It's also a large project for a small crew.

That's so often the answer for this kind of stuff.

I'll just say that I'd be plenty willing to look at ads if it meant you guys could hire some more programmers.

Sponsored posts, even!
posted by floam at 2:03 PM on April 24, 2010


The mobile version of Metafilter works great - what's wrong with it that an alternate client would solve?

Besides the obvious problem that you can't sell it.
posted by odinsdream at 6:54 PM on April 24, 2010


What's wrong with the mobile version? It's comprised of web pages, and thus cumbersome compared to a dedicated client; you have to reload pages and scroll through them to find new posts, and pinch-zoom in on forms. A dedicated data-driven client could ping the APIs, fetch new posts and new comments on your posts/threads you've commented on and present them in a way that cuts out a lot of the fiddling around. And when you're working on a handheld device with a tiny screen and no keyboard, the inconveniences of traditional web interfaces become more pronounced than on a desktop.
posted by acb at 7:12 PM on April 24, 2010


Irrespective of specific API support, MetaFilter is big enough now the Powers That Be might consider creating a skunkworks+sandbox message subsite where people can test mobile apps, such as the one proposed, and scripts of various origin under controlled conditions. It would avoid the need for MetaTalk topics asking for testers or requesting a new script/app/bookmarklet to get a desired feature. A subsite removes the need for "ignore this post, I need to see if something works" type posts -- not that such posts appear to be allowed anyway, but they can be extremely useful in tool tests to check different posting circumstances and conditions.

Such a subsite could also serve as a gathering place for developers, authors, programmers, and their testers to cross-communicate on native technical, operational, testing, and support details and issues without cluttering up the gray for the vast majority of other users who won't care or don't have a clue what the discussion is about.

A number of the big traffic sites have development, sandbox, and skunkworks sections or native support, e.g. Facebook and Wikipedia, so it's not a novel concept to apply to MetaFilter. It could benefit MetaFilter owners, admins, third-party developers, and, ultimately the users who gain from new and improved tools.
posted by mdevore at 9:19 PM on April 24, 2010 [1 favorite]


mdevore, that sounds like a great idea once we're actively trying to build a developer community. We're a long way from that right now. We have several layers of decisions to make before we even get to the point where we're building an API, let alone building a test bed for API applications. Facebook, Wikipedia, et al are massive projects that are many times over the size of MetaFilter. We employ four people. It's flattering to be considered in the same league as sites with that level of development infrastructure, but we're just not at that scale. And in many ways we don't want to be.

As I mentioned before, we don't want to encourage this type of mobile app development at the present time. We have to make sure an API is something we are able to devote enough resources to develop, support, sustain, explain, police, and ask the community to support. We're just not there yet.
posted by pb (staff) at 10:15 PM on April 24, 2010


« Older 23 and Me screening, on the cheap!   |   Got my goatse? Newer »

You are not logged in, either login or create an account to post comments