At 02:09 AM 6/5/98 -0700, Roy T. Fielding wrote:
>A network-based API is an interface that exists on the network itself:
>a gateway through which different applications can communicate by
>restricting themselves to a set of well-known semantics (syntax too,
>but that's the easy part).
So, if we decide to wrap this interface programmatically (ala libwww), have
we lost any information? I don't think so. They're both equally
expressive, and express the same info.
>A library-based API does a lot more for the programmer, but in doing so
>creates a great deal more complexity and baggage than is needed by any
>one system, is less portable in a heterogeneous network, and always
>results in genericity being preferred over performance. As a side-effect,
>it also leads to lazy development (blaming the API code for everything)
>and failure to account for non-cooperative behavior by other parties
>in the communication.
Genericity derives from the explicit attempt to steer clear of the "build
your own transport protocol" (or whatever) syndrome. An admiral goal.
>A network-based API does not place any restrictions on the application
>code aside from the need to read/write to the network, but does place
>much larger restrictions on the set of semantics that can be effectively
>communicated across the interface. On the plus side, performance is only
>bounded by the protocol design and not by any particular implementation
>of that design.
So what's the difference between a "network-based API" and a "wire
protocol"? Human-parsable vs. not?
>Mind you, there are various layers involved here -- systems like the Web
>use one library API (sockets) in order to access several network-based
>APIs (e.g., HTTP and FTP), but the socket API itself is below the
>application-layer. Likewise, libwww is an interesting cross-breed
>in that it is a library-based API for accessing a network-based API, and
>thus provides reusable code without the assumption that the other
>communicating applications are using libwww as well.
And similarly, if I'm a CORBA object, you can make requests of me via IIOP.
But I don't care what library API you're programmed to. I only care that
you're spitting out IIOP. It could be through RMI, Tcl, Python, etc..
HTTP has "GET". IIOP has "Request" tokenized as 0x00.
>Contrast this with
>CORBA, which only allows communication via an ORB,
Not true (as mentioned in the previous paragraph). Just speak IIOP.
>thereby leading IIOP
>to assume too much about what the parties are communicating.
It only assumes point-to-point request/response.
MB
-- Mark Baker. CTO, Beduin Communications Corp Ottawa, Ontario, CANADA http://www.beduin.com