From P2P Foundation
Revision as of 05:22, 24 March 2012 by Mbauwens (talk | contribs) (Created page with " '''= protocols are agreements among a set of parties on a sequence of operations and the format of messages that will be used to communicate for a given purpose.''' =Descripti...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

= protocols are agreements among a set of parties on a sequence of operations and the format of messages that will be used to communicate for a given purpose.


Phil Windley:

'Protocols are agreements among a set of parties on a sequence of operations and the format of messages that will be used to communicate for a given purpose. For example, SMTP, Simple Mail Transport Protocol is the protocol that enables email servers to exchange email messages with one another.

Distributed systems depend on protocols to function. In Protocol (PDF), Andrew Galloway says “protocols are the enemy of bureaucracy, of rigid hierarchy, and of centralization.” Protocols enable ways to overpower and supplant places.

Protocols have both syntactic and semantic elements. For example, there is a specific form or syntax that the SMTP protocol prescribes for indicating the recipient of the message. The fact that it indicates the message recipient is the semantics of that particular field.

Internet protocols usually rely on other protocols. For example, actually doing email involves not just SMTP, defining how to exchange email messages, but also other protocols like DNS for name resolution, IMAP or POP for mailbox management, and MIME for specifying message content. Then there’s the “envelop” protocol. For example, SMTP doesn’t talk about transport, that’s TCP/IP’s job. TCP/IP is, for SMTP, and envelop protocol." (


  • "The Internet is a creature born of protocol." [1]


Protocols vs APIs

Phil Windley:

Some people are rather militant about properly distinguishing APIs from protocols. I’ve gotten comments from people that say things like “that’s a protocol, not an API!” Lately it’s become fashionable to call any thing with a REST interface an “API”—even when they’re more properly protocols. I think some of this is simple confusion, but it’s also an attempt to make things sound easier. No company wants programmers to think their system is hard to use and protocols sound hard.

What’s more, some Web APIs are pretty straightforward request-response systems where protocol sounds overly ambitious. For those interfaces, API is probably the right word. But other so-called APIs are really protocols. People have started to refer to these as “push” APIs. Twilio’s API, for example is a full blown protocol as it clearly defines an agreement on sequences of operations and formats for messages with the goal of accomplishing telephony tasks using the Twilio system. Modulo intellectual property issues, one could imagine another online PBX adopting the Twilio API as a standard.

One of my goals is to get more Web APIs to send events—to become more properly protocols instead of mere request-response based APIs. My motivation is systems that are more loosely coupled and better able to act as peers in orchestrated Web interactions. Sam Curren and I have developed the Evented API specification to come up with a standard way of adding events to APIs, making them more properly protocols.


Phil Windley:

"Programmers reverence protocols. We think of protocols as something given to us from on high by the Cerfs, Postels, and Berners-Lees of the world. But the truth is that programmers build protocols all the time. Sometimes these are ad hoc and other times they are built with the help of a metaprotocol.

A metaprotocol is a protocol for building or describing other protocols. You’re undoubtedly familiar with some metaprotocols even if you haven’t thought of them that way before. SOAP, RMI, CORBA, and JSON are all examples of metaprotocols. We often use words like framework, IDL, specification, or even just format when we’re talking about metaprotocols. The page from Caucho Technology on metaprotocol taxonomy does a pretty good job of classifying various metaprotocols.

RMI, for example is a metaprotocol that defines the syntax of interactions between classes. RMI specifications are given by the Java class definition using reflection. Whenever someone uses RMI to specify the interactions between Java classes, they’re defining a machine-readable protocol.

The Evented API specification also defines a metaprotocol. Events are transported over HTTP and the specification defines a format (i.e. syntax) for how events can be encoded."

Using the Evented API specification, however, requires that a developer further define the events that will be raised. By defining the event domain and type as well as the required and optional attributes for each event type, the developer creates a protocol for sending notifications. We’ll see example of this below." (

More Information