August 24, 2007
@ 06:44 PM
Comments [6]
Microformats are not an API

Recently, my status message on Facebook was I'm now convinced microformats are a stupid idea. Shortly afterwards I got a private message from Scott Beaudreau asking me to clarify my statement. On reflection, I realize that what I find stupid is when people suggest using microformats and screen scraping techiques instead of utilizing an API when the situation calls for one. For example, the social network portability proposal on the microformats wiki states

The "How To" for social network profile sites that want to solve the above problems and achieve the above goals.

  1. Publish microformats in your user profiles:
    1. implement hCard on user profile pages. See hcard-supporting-profiles for sites that have already done this.
    2. implement hCard+XFN on the list of friends on your user profile pages. See hcard-xfn-supporting-friends-lists for sites that already do this. (e.g. [Twitter (http://twitter.com/)]).
  2. Subscribe to microformats for your user profiles:
    1. when signing up a new user:
      1. let a user fill out and "auto-sync" from one of their existing hcard-supporting-profiles, their name, their icon etc. Satisfaction Inc already supports this. (http://microformats.org/blog/2007/06/21/microformatsorg-turns-2/)
      2. let a user fill out and "auto-sync" their list of friends from one of their existing hCard+XFN supporting friends lists. Dopplr.com already supports this.

It boggles my mind to see the suggestion that applications should poll HTML pages to do data synchronization instead of utilizing an API. Instead of calling friends.get, why don't we just grab the entire friends page then parse out the handful of useful data that we actually need.

There are a number of places microformats are a good fit, especially in situations where the client application has to parse the entire HTML document anyway. Examples include using hCard to enable features like Live Clipboard or using hReview and hCalendar to help microformat search engines. However using them as a replacement for an API or an RSS feed is like using boxing gloves instead of oven mitts when baking a pie.

If all you have is a hammer, everything looks like a nail.

Now playing: D12 - American Psycho II (feat. B-Real)


 

Categories: Web Development | XML Web Services

« It isn't OpenID vs. Windows Live ID (Web... | Home | Facebook Spam »
Friday, 24 August 2007 20:46:41 (GMT Daylight Time, UTC+01:00)
"It boggles my mind to see the suggestion that applications should poll HTML pages to do data synchronization instead of utilizing an API."

Why?

Screen scraping has always been and will likely remain the pseudo-api of last resort. A more interesting argument is that web site operators should ditch the API and just spit out structured HTML that can double both as a web page and an API.
pwb
Friday, 24 August 2007 22:25:43 (GMT Daylight Time, UTC+01:00)
I don't find that argument appealing. Web site operators should prefer APIs to microformat because APIs are
(i) more likely to be more efficient for data transfer
(ii) more flexible because they can have options that don't necessarily have an analog in the end user facing Web page (e.g. get me the favorite music and books of all my friends is an API call in the Facebook API that doesn't have a UI analog)
(iii) easier to monitor if they are separate from regular Web traffic

The only people who should be encouraged to utilize microformats in such situations are people who don't actually control the Web site (e.g. bloggers on a hosted blogging service). Besides that exception using microformats in such situations is using the wrong tool for the job.
Dare Obasanjo
Saturday, 25 August 2007 03:56:02 (GMT Daylight Time, UTC+01:00)
My trackbacks ain't working, so here's one, manually wound-up:

http://glazkov.com/blog/horrific-markup-live-spaces/
Dimitri Glazkov
Saturday, 25 August 2007 05:00:21 (GMT Daylight Time, UTC+01:00)
"what I find stupid is when people suggest using microformats and screen scraping techiques instead of utilizing an API when the situation calls for one"

True.

However, while both excess content serving and functionality limitations are downsides, one upside is the ability to easily code against 1 standard supported by n services vs. coding against n APIs.

Are there any efforts underway to standardize the "friends.get" interface across services?
Adam Herscher
Saturday, 25 August 2007 12:10:10 (GMT Daylight Time, UTC+01:00)
I agree with Adam. API's are nice and efficient ways to move data, very specific data. But writing code for every single API, which often change each time the wind blows, seems untenable.

If we think about some of the thing the Mozilla folks are working on, microformats become really useful standards. I can browse any site and immediately have useful information back.

This slide presentation is good at demonstrating just some of the capabilities of microformats in the browser.
http://www.xfront.com/microformats/Microformat-Demonstration.html
Elroy Jetson
Tuesday, 28 August 2007 03:37:04 (GMT Daylight Time, UTC+01:00)
Dare,

By the way, I don't buy the scraping argument. Things change too often, and from site to site.

As far as API goes:

friends.get(me)

may be machine readable, but

a) it lives on another URL.
b) it's dynamic instead of static.
c) it only returns friends

With microformats, you can construct or imply RDF triples from a single web page. I thought that's pretty cool.
Chui
Comments are closed.