OPML API
Kevin Burton is talking about OPML APIs. Here's how I'd design an API for subscription management. Let's take an endpoint, say Subscription.aspx, or subscription.php, or subscription.scm, or just /; whatever makes you happy. Anyway, our API:
- GET
- GET on the endpoint returns the OPML document that's stored on the server.
- POST
- POSTing an OPML document to the endpoint amounts to merging subscription lists; the response to this call is the union of what a GET would have returned and whatever the client sent
- PUT
- Replaces the OPML document on the server with what the client sent. ERH has a great post on why this works.
The tricky part is deleting subscriptions. You could invent a deleted attribute in the OPML (possibly namespaced to avoid collisions), i.e. a "tombstone" in Microsoft parlance. Or you could say that upon creation of a subscription, the server assigns an identifier to the new subscription, so Subscription.aspx/42 is the URL of the subscription, and a DELETE on that url deletes the subscription, while a DELETE on Subscription.aspx deletes the whole subscription list (effectively, a PUT with an empty OPML document). Some people seem to get irritated when you start assigning new IDs to things that already have a perfectly good URI to identify them, though. And some User-Agents are PUT and DELETE impaired. And you need at least one: if you can DELETE but not PUT, then PUT can be implemented with a combination of DELETE and POST, if you can PUT but not DELETE, then you can accomplish DELETE with a GET and PUT. But PUT and DELETE go in pairs, either you have them, or you don't. So it seems like the deleted flag would be a necessity.
So there you have it, one extension attribute in OPML (prior art, zero extensions to HTTP, no XML-RPC - or SOAP - induced complexity.