4/27/2002 4:08:28 AM, Bill de hÓra <> wrote:
>
>I wonder where protocols fit in all this. If you don't have a
>properly documented protocol, I don't see how getting at the bits
>helps. Is it assumed that either the APIs or the bits are backed by
>a protocol? Or are you thinking about APIs as a way of pretending
>the network/protocol isn't really there?
In OOP-ese, APIs present an abstraction of the underlying
process or protocol, allowing the "bits on the wire" (or machine
instructions, or whatever) to be encapsulated, thus the
bits behind the abstraction can be modified, replaced, ported,
etc. with minimal impact on the application. There are lots of
C programs out there that are carefully written to standard
APIs (or libraries that abstract away the differences among standards)
that run on everything from handhelds to mainframes. That obviously
wouldn't be possible if people wrote to the "bits on the wire".
Also, it works if the "network/protocol isn't really there", and
the API just keeps people in the state/transitions that actually
work.
Of course there's a dark side to this, ESPECIALLY when we're talking
about XML, which was supposed to be simple and standardized enough
to provide a consistent set of bits on the wire that could be
programmed to on any platform: if you can't stand a little "pain"
and write to the interoperable standards, you won't get the
platform/vendor/language-neutrality "gain" that attracted you to
XML and the Web in the first place.
This is a common theme in the web services debate. Those who are
building the higher layer APIs say that they are leveraging the power
of HTTP, URIs, and XML and simply providing convenient abstractions
that ordinary programmers can work with. We've identified two problems:
- As the SOAP-RPC vs URI/HTTP/XML debate has made clear, the
abstractions may hide the part of the underlying protocol that gives
it the power that is supposedly being leveraged.
- The bits on the wire ARE the "standard" in the Web, and it doesn't
take a clinical paranoid to wonder whether the name of the API game isn't
"embrace, abstract, replace, and then extinguish."
I think the lesson here is "build your own abstractions and APIs on top
of the real, basic, interoperable standards." Don't wait for some industry
consortium or inter-agency task force to build one-size-fits-all
abstractions; that won't happen, or if it does the
"standards" will be so vague and broad that they don't give real interop
anyway. And be especially careful not to become dependent on the APIs
and abstractions offered by those who may be offering convenience
at the price of your soul.
In the world of the Harry Potter books, wizard parents teach their children
"Never trust anything that appears intelligent if you don't know where it
keeps its brain," because it may be powered by dark magic that can
enslave you. The same advice might be given to those who are offered
"smart" APIs and GUIs and frameworks that hide all those ugly
URI, HTTP, and XML bits on the wire.
