I'm glad Joe Gregorio frankly assessed Atompub's meager adoption.
Atompub served as an experiment to confirm the REST hypothesis: If you construct distributed systems that look like the world wide web, the world will adopt them broadly and quickly -- the way we adopted the web itself. *
Lesson learned: the world's most successful distributed applications run on the web's architecture. That doesn't mean that by designing around web architecture, you will build the world's most successful distributed application.
Atompub came along at the time a critical mass of thought was building in favor of adopting the web architecture for designing new systems, rather than the ill-named "web services", SOAP and RPC model. Early drafts of Atompub allowed for a SOAP envelope.
The RESTful style prevailed, on its many merits. We got caching, and a resource oriented model, and a small, uniform interface.
But what the real, browser plus HTML web has, that RESTful systems don't, is the user agent. The human in front of her browser. An intelligence that reads and understands the meaning of "Author name" and "Title", and fills in an HTML form using queries against her personal database, stored in her brain.
As Joe put it, the problem is that Atompub clients aren't web browsers.
RESTful systems that aren't web browsers try to substitute understanding of media types for that intelligence. Compare Atom clients to HTML browsers.
An "Atom application" is some sort of content management system: a system that understands the semantics of feed documents. An Atom agent populates <author> and <title> elements. Only machines understand the meaning of <link rel="edit">. It's a world constrained to a narrow range of meanings.
But an HTML application can do anything. A human reads some text next to a form field, labelled "Author name", or "Preferred airline", and enters meaningful answers. If you are writing the kind of content management system where "Preferred airline" is a meaningful concept, HTML might be the way to go. There's no such concept in an Atom feed document. You get to present your own user interface, too.
RESTfully designed systems might profit from superior evolvability, cacheability, and interoperability over RPC systems. They are of the web. But they are not the web. The web is in your browser. The web is HTML.
*The hypothesis was not part of Roy Fielding's thesis. It's a hypothesis that many REST proponents, including me, have deployed.
Hugh Winkler holding forth on computing and the Web
Saturday, April 18, 2009
Subscribe to:
Post Comments (Atom)
5 comments:
From Roy's thesis:
"REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state."
The last one is, definitely, where HTML gets into REST. hypermedia as engine of application state means that the (UA) choices are effected by jumping to (GETting) different, related resources and modifying/creating (POSTint).
So I see HTML as the essential "engine" of REST, but I might have completely missed the point of your post.
@santi Atompub is RESTful yet its hypermedia is XML based, not HTML. HTML is the essential engine of the web, but not of REST. REST != the web.
The XML Atompub uses has rich meanings for the domain of content management. HTML has weaker semantics for the domain, but that hasn't been a barrier to constructing interoperable programs (e.g. Facebook and Twitter apis). The more general HTML (+ JSON) approach wins when you are designing APIs and clients, I guess because it offers more scope.
Isn't "hypermedia" the engine? And doesn't that just mean links [simplified]? I don't see what HTML has to do with it, except that HTML happens to be the standard way of delivering hyper(linked )media to *users*. On the other hand, XML or JSON representations containing state and links are just as "hyper", aren't they.
@Wyatt, That's the theory: XML is just another form of hypermedia, and Atompub is a RESTful system designed around that.
I guess one conclusion we can draw from the Atompub experiment, is that XML really isn't "as hyper" as HTML. The webapp designers and consumers have voted.
My article isn't saying that Atompub isn't RESTful. It's exploring why this RESTful system hasn't achieved, fully, the ambitions some held for it.
Is it Atom's fault that the client's arent clever enough to utilise everything that it exposes?
Perhaps in 5 years time, client technology will have evolved to such a point that Atom will be more fully utilised. Joe's argument is perhaps an indictment against the 'build it, they will come' philosophy, but not necessarily against REST or even Atom itself.
Perhaps there is something else impeding the development/adoption of inteligent non human operated web clients?
Post a Comment