Deconstructing the AtomAPI

Yesterdays idea of applying the AtomAPI to wikis got me thinking about the AtomAPI more generally. The idea of using a link tag on the web page to be edited points to idea that some parts of the AtomAPI could be eliminated. So let't take some time and push that idea to its logical extreme to see how small the AtomAPI could be made.

N.B. What follows is a thought experiment. I am not proposing this as revision 8 of the AtomAPI, it is merely a thought experiment to flesh out some ideas and to generate some discussion.

So from yesterdays discussion we know that the search facet can be removed from the API in favor of letting the browser be used to naviagte the site in choosing which page to edit. In place of the seach facet each page has a link tag of the form:

<link rel="service.edit" type="application/x.atom+xml" 
      href="entryURI goes here" 
      title="A name for what you would be editing">

And that entryURI is what you do GET, PUT and DELETE against to update that entry.

That's just a quick re-cap from yesterdays discussion. Now let's move forward and look at the rest of the facets in the AtomAPI. The CommentAPI portion of the AtomAPI already works in a similar manner, i.e. a link tag on HTML pages points to the commentURI so nothing there needs to change.

<link rel="service.comment" type="application/x.atom+xml" 
      href="commentURI goes here" 
      title="A name for what you are commenting on.">

That leaves the facets for creating an entry, editing preferences, and editing templates.

Editing templates could work the same way as editing an entry. That is, create a web page for each template. On that page is a link tag to an entryURI. Doing a GET on that entryURI gets you an Atom representation of that template. You can then edit and PUT that representation back to update it.

Preferences are a bit out of place, so for now, as part of the thought experiment, we'll just drop them. Wasn't that easy?

The very last facet of the API is for creating of a new entry. That could be handled by putting a link tag on the main page with the URI that you POST to to create a new entry.

<link rel="service.create" type="application/x.atom+xml" 
      href="createURI goes here" 
      title="The name of the site.">

If you've followed along this far then you realize the the Introspection file has now been orphaned and can be dropped. That's really suprising that so much of the AtomAPI can go away with very little loss in functionality, i.e. only the preferences part of the API has been dropped. So in summary we are left with three link tags and a single file format.

1. Create - A link tag that points to the URI that you would POST an Atom Entry to to create a new entry.
2. Edit - A ling tag that points to the entryURI for the page you are viewing. Use GET, PUT and DELETE to update. Works for both entries and templates.
3. Comment - A link tag that points to the URI to POST comment entries to.

I know that would certainly make the RFC easier to edit, it leverages the current HTML infrastructure better, and opens up the API for things like editing Wikis. It seems a bit extreme to me, but elegant, and I'd really like to hear what you think of this.