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.
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.
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
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
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]
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]
posted by blue_beetle at 8:26 AM on April 24, 2010 [1 favorite]
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
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 acb at 9:39 AM 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
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]
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
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
You are not logged in, either login or create an account to post comments
posted by xorry at 6:04 AM on April 24, 2010 [1 favorite]