Make an API of your website

Mar 16, 2008

Lately I’ve been thinking a lot about data portability in terms of API’s, microformats and standards like SIOC, FOAF, OWL and APML. What fascinates me is that data portability enables people to share and move their data around the web seamlessly. I wrote about some microformats and standards for the semantic web a few days ago, but what about the API’s?

Nowadays, an API most often comes in the form of a REST service that returns JSON or XML, so that both JavaScript and server-side technologies can use them. It makes sense and it promote data portability. Then think about a website. Some parts of it are tagged up with various microformats like XFN, hCard and hCalendar, but what about the rest of the content?

My idea is to render any webpage in either XML or JSON if a certain parameter is added to the URL. It could look like this:

www.example.com/about.aspx?format=xml

Then the about.aspx page would render the output as XML for machines to read and thereby have some sort of read-only API. The standard could be RSS or ATOM or both. Now any machine can read the content of your website easily. Think about how easy it must be for search engines to index an RSS representation of a webpage instead of going through all the excess mark-up and style information.

* Only $4.95/month ASP.NET & Windows 2008 + IIS 7 Hosting! FREE SQL Included

Checklist for high quality websites part 1A checklist for websitesMeasure the success of your websiteDefine conversion points in order to measure the success of your websiteThe use of audio on a websiteThe use of audio files can create a more loyal visitor base and help support your website's message.

Comments (12) -

Jakob Andersen

3/16/2008 8:57:52 PM #

If any webpage could be served as RSS, ATOM and JSON then the content of that page could be consumed in a multitude of ways. The best thing is that it is relatively easy to implement. Because it is so easy I can’t stop wondering if there is a reason no one has done it before.

No reason to reinvent the wheel, we have had this for years.Having content in XML and having that transformed to HTML(RSS/ATOM/JSON/Whatever using XSLT?

And another point which the before mentioned XML/XSLT kombination also suffers from is that it isn't an easy task to consume data if you have no predefined format, a quick example:

<person>
      <Name>Mads</Name>
      <Items>
         Insomnia
      </Items>
</person>

(Stupid example but it proves to show my point) How should i use this data for anything? I could make code that could consume this (whether its a list of Mads favorite movies or a list of disorders that Mads has). And whoila thats it, i can present this in my taskbar/phone/webpage/whatever. But how about when the next guy goes to make the same page on his website and uses a completely different format, then i would have to read this format as well. Okay you say, here is the answer: we need schemas so that folks do the same formats all over....... So thats approximately one schema for every webpage out there or a pool of very large and confusing schemas making room for everypossible data you would want to have in a pagetype.

Bill

3/16/2008 11:44:59 PM #

WCF does this already. You can specify different sub-endpoint bindings for any given service file.

Native ones off the top of my head:
-Soap11
-Soap12
-JSON

Guidmaster

3/17/2008 12:14:08 AM #

And ACF also supports RSS and ATOM. I have made a screencast about RSS and ATOM in WCF. You can se it right here: dotnetforum.dk/.../...st-rss-amp-atom-med-wcf.aspx

Dave Scriven

3/17/2008 12:32:17 AM #

The point of XHTML was to make your pages machine readable, your pages *are* machine readable. Google is an example of a machine reading your site.

abbr, acronym, @title, @alt, @summary, @id etc. They are all meaningful markup elements and attributes.

I think it's a mistake to think about your XHTML markup as "excess". HTML 5 will be adding more semantic elements such as <nav/>, <datagrid/>, <header/>, <article/> that will give even more meaning to your pages. Also, is the navigation of your site really excess too? Perhaps they are less important with things like Google sitemap now.

A page is exposed as the DOM to JavaScript too, which is more than read-only. The entire element tree is effectively a JSON object that can be read and modified.

You see what I'm getting at though? There's plenty of meaning in XHTML as it is, do we really need pages displayed in ATOM too? And do we really need a new object for JavaScript?

Denny Ferrassoli

3/17/2008 3:53:30 AM #

Hey Mads, what you're talking about has been done in ASP.NET MVC. Check it out here: weblogs.asp.net/.../...-asp-net-mvc-framework.aspx

Mads Kristensen

3/17/2008 6:25:15 AM #

@Jakob,
I know we could have done this for years. That's kind of my point. It is very easy to do. As I suggested, we should keep to RSS or ATOM standards so we don't end up in the situation you describe.

@Dave,
XHTML does not provide a strong format that is easily machine readable. When is something content and when it is a copyright footer? XHTML does not tell the machines that. RSS or ATOM would separate it so it's totally clear what the content and its metadata is. HTML 5 will take care of this problem in some ways, but how many years do you think we should wait for it to be a fully functional and browser accepted standard? 5 years?

@Morten,
I need to look at the WCF stuff. Thanks for the link.

Jakob Andersen

3/17/2008 6:55:50 AM #

Mads:

So you would standardize every kind of page that is found on a website?

- Favorite Movielisting standard
- Product list standard
- About us standard
- About me standard
- Catpage standard
- Dogpage standard

etc. ?

Mads Kristensen

3/17/2008 7:15:47 AM #

@Jakob,
No, one standard called "webpage" that is RSS or ATOM. Microformats takes care of listings, contact information, events, reviews etc. so we don't need that. Just serve the content and meta data of a page as RSS.

Jakob Andersen

3/17/2008 7:21:41 AM #

I would like to see that, however i am frightened because the format will not be able to contain all the data you need. For instance can people wan't very different information attached to an event. And trying to make these microformats support all possible informations will make them extremely bloated. It would be the same thing as to try to make a databasestructure suitable for all applications.

Dave Scriven

3/17/2008 10:08:04 AM #

You're right, Mads. I'm just not convinced that syndication formats will hold enough information. Don't get me wrong, I like the idea I'm just trying to imagine how much it could offer over XHTML? i.e. why do it when XHTML is machine readable but holds less semantic elements. What's the benefit?

Then again, the syndication XML can still hold XHTML so I guess it's the best of both worlds.

Jesse Foster

3/17/2008 8:04:27 PM #

I think this guy is really on to something, when it comes to this topic. It's almost exactly what you are talking about, with respect to the querystring format selector.

www.aaronlerch.com/.../

Jesse Foster | jf26028

Sukesh Ashok Kumar

3/23/2008 8:10:27 AM #

Hey guys,
This topic sounds interesting and I had ventured into this 5+ years ago before RSS/ATOM/JSON etc were so popular. I built my previous website using pure XML/XSLT and kept a copy because I felt it would become popular in future

Check it out => http://v4cnet.awesomeideas.net
Pages other than Home,Contact are pure XML/XSL and no javascript or server side programming involved!

Pingbacks and trackbacks (1)+

Comments are closed

Make an API of your website

Related posts

Comments (12) -

Pingbacks and trackbacks (1)+

About the author

Twitter

Month List

Disclaimer