Will the Atom API support semi-smart phones?
by ZetaGecko | Add Your Comments | Atom/RSS
The Atom API will specify an open standard for editing blogs, Atom feeds, and other such resources. Any program or device will then be able to interact with any Atom server software that supports the API. As long as it meets the minimum technical requirements, that is. In the past, we planned to build in a fallback mechanism for use by software that didn't support all of the required technologies, but there is now discussion underway about dropping the fallback mechanism. If that happens, some of today's so-called "smart phones" won't have access to some parts of the API.
Briefly, the issue at hand is support for HTTP's PUT and DELETE methods. When you load a webpage, your browser generally uses an HTTP GET to do so. When you submit a web form, your browser generally uses an HTTP POST. (There are many exceptions to both, but you get the idea). DELETE is used to delete things from the web, and PUT is similar to POST, but...well, different in some ways. Just about any web device can handle GET and POST, but not all support PUT and DELETE. The fallback mechanism would make the PUT and DELETE functionality available via POST so that pretty much anyone would be able to use it.
Why drop the fallback mechanism? Because if we provide a fallback mechanism, we'll have to continue to support it for a very long time, and phone makers and others will have little incentive to update their systems to support the preferred mechanism. Adding support for PUT and DELETE shouldn't (as far as I can imagine) be particularly difficult. It's mainly a matter of giving people a reason to bother.
On the other hand, how difficult would it be to support a fallback mechanism? The details haven't been fleshed out, but it seems that most systems that don't support PUT and DELETE would be covered by the simple addition of an extra HTTP header to indicate that, although the request was POSTed, what was really desired was PUT or DELETE. Honestly, supporting such a fallback just doesn't seem that onerous. I lean toward supporting the fallback mechanism. Make as many people happy as possible today. It's not going to be that painful.
Or I may be wrong. Whatever.