Couldn't agree more. I think the thing to do is develop the system using
a protocol and then write a simple
API written on top of the protocol. They can both inform each other to
the benifit of each other.
HTTP is a protocol but we generally use some API instead of coding to
the raw protocol. The nice
thing is that we can get any number of APIs providing different service
levels.
I defined, for example, a database protocol for a project. Developers
cut and pasted great blobs
of code to create and handle messages with little understanding of what
was really happening.
Many bugs were the result. Recently i built
a simple API over the protocol and the protocol can now be used with 2
line of code.
Yet it is still openly client server and i can evolve each independently
of each other.
I would never advocate an API only approach because it requires a port
of the API to the
machine you are using and the language you are using. Not exactly a
recipe for mass
adoption. Using the protocol approach we can have the best of both worlds.
Tim Bray wrote:
> I had a big argument over something Dave Winer said a few years ago
> and he captured my rant and posted it at
> http://static.userland.com/misc/timBrayOnSdk.html
>
> For what it's worth, I think that at the architecture level, the
> choice between demanding to see the bits-on-the-wire and being
> satisfied with an API is probably the deepest one there is. -Tim
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
