|
I am not very happy with this article. Reasons:
The Atom API was designed because the MetaWeblog API proved that RPC-based APIs were simply the wrong solution for this problem.
Wrong. This is not the case. What was discovered was that if people start out with a data representation and stick heavily to this data representation, a REST style API is much more fitting than a XMLRPC API. But if you do your data design in the terms of Collections, Structures, simple data types first - an XMLRPC API is still the way to go.
There is an especially annoying bit in the article: the what goes over the wire bit. In the context of XMLRPC calls, the wire format is irrelevant. This was a constant point of confusion in the wiki for quite some time, as document centric view and functionality (API) centric view are quite different in this area. If you work with abstract data models and distributed functionality, you don't necessarily have to care for the wire format. It would be quite easy to get the same results (functionality wise) as Atom by specifying data models (in terms of collections, structures, simple data types) and a classic API specifications with XMLRPC. There is no hidden law that forces one to solve this in the document centric way that Atom has chosen. I am not against the document centric way - it has it's benefits. But the underlying tone of the article is that XMLRPC interfaces and data structures are inferior to the Atom approach, especially because of the wire format of XMLRPC - and that hidden statement is plain ridiculous.
Well-defined data model -- with schemas and everything!
Wrong. Nowhere in the Atom spec there is a data model defined. What is defined is a data representation. And specifications of this representation. And APIs that build on this representation. This is not to downplay the accomplishment - to create a usefull data representation with spec, API and all is a very big step in itself. But it isn't a data model. It can be mirrored in a data model - or can reflect with data models, sure.
Doc-literal style web services, not RPC
This wasn't a goal of Atom. It was an outcome of the discussion based on an adhoc spec and sample and on how to work with this. It was a direct outc ome of the fact that more people preferred to work document and representation based than data model based. Would the start have been an abstract data model, the outcome might have been different (not necessarily better!). Atom never had fixed goals in the early design phase, beside being something built by community to solve a defined problem area (and even that was shifting while discussing it). To state that getting rid of XMLRPC was a design goal of Atom is plain wrong.
Many of the stated design goals in that article were actually just outcomes of discussions. For example the taking full advantage of HTTP was absolutely not an easy accomplishment - there were lots of discussions around this, wether PUT and DELETE were acceptable or should be avoided! Even one of the first prototype implementations of the API didn't use PUT and DELETE!
Previous weblog services had no concept of API discovery.
Wrong. There are several takes at API discovery (telling the XMLRPC connector URL inside data representation formats like rendered HTML or RSS and by using introspection on those connectors. This was just in it's infancy, so don't expect many fledged out specs, though. It's in it's infancy with Atom, too. API discovery is never an easy thing, especially if you need extensibility in your API. The document centric approach in Atom does help here, as the API spec itself has much less weight on functionality (only providing some primitive operations) and much more weight on representation (by just pointing over to some big honking document telling how to parse what you get). This is one of the very nice points about the Atom spec in special and the document centric view in general.
Sorry, Mark, you won't gain good marks from me for this one. Drop out the XMLRPC bashing and the (historical wrong) hype, and the rest makes quite a good introduction into Atoms functionality and power. But with the first part attached, it makes bad feelings with people that like to follow different paths to implementations.
BTW: One problem with Atom isn't mentioned in the article at all. It has to do with the document centric view - because of this, you are more in a naked objects world. Your documents are your addressable objects. What you see is your object. There isn't much substructuring of data - if something has an URL, it's an object and it's one object. This is in direct conflict with microcontent ideas, as those are only parts of visible objects. Sure, URLs can have a fragment part and you can use that to address subparts of an object, but this is a flat namespace. To create hierarchic subdivided content objects based on this is a bit wacky. It can be done, for sure. And you can do it by only working on your base content and defining some pages as derived objects that just pull stuff from the central repository and not having their own actual functionality, so it's not a big problem. But it is a bit problematic - when are you talking about the visible object, the page, when about the template that renders this page and when are you talking about the data that makes up the page.
|
