Sitting down at a chess board, across the table from an opponent, a contract exists. This contract is that a game of chess will take place, and the rules of chess will be followed by both players. The rules, of course, define the constraints of the game; bishops move diagonally, knights in a 2/1 “L” pattern, white moves first, etc.. Should a player mistake the chess pieces for checkers, and attempt to “jump” another piece, or move a rook diagonally, the constraints of the game have been violated, and chess is no longer being played.
Such is the case on the Internet, with application protocols. When one party opens a connection to another party, a contract is in effect; the contract associated with the TCP port to which an application protocol is bound. As an example, port 80 is for the Web, and any protocol used with it is expected to conform to the uniform interface constraint, meaning that any method being invoked is uniformly applicable to all resources. To not do this, is to play checkers with a chess set. And of course, that’s what Web services are doing.
Another way of looking at this is that most Web services proponents refer to application protocols as transport protocols, which is wrong (most of them are transfer protocols), but explains their tunneling-centric mindset, as they are generally not aware that an application layer contract exists when, for example, you telnet to port 80. Because when you have telnetted to port 80, and are sitting there looking at the flashing cursor, you know what methods you can invoke (OPTIONS, GET, etc..). With Web services, if you telnet to port 80, port 25 (SMTP), or any other, you’re ignoring the existing application contract, and instead count on some separate and different WSDL-defined contract, which you don’t know how to find. Let me repeat and rephrase this, for emphasis; WSDL operations are at the same layer as application protocol methods. And again; HTTP GET is an application semantic, the same as “getStockQuote”.
This is the first step towards understanding Web architecture. Well, it was my first step at least.
Thoughts?
Contracts are for people, not things
This article exemplifies what's wrong with the REST crowd. The existence of a chess set doesn't bind two parties to any contract to follow the FIDE rules. Certainly, my 3 year old twin sons don't think so. They enjoy using my chess set without any knowledge of the rules of chess. Likewise, Lord Dunsany created many interesting variations on the basic game of chess that used (mostly) the same board and pieces.
When two people sit down at a chess set, the people agree to play a game. Translate the analogy to a deck of cards and you will soon see the position of REST folks is too limiting. If you want to play bridge, that's fine. I may want to play poker. Arguing over which one is better is just plain stupid. You find your bridge partners and I'll find my poker buddies. Sometimes I like to play bridge too and then we can play together, but stop trying to confiscate my deck.
Contracts are for people, not things
You're missing the point by focusing on the analogy. It is just an analogy of course. And you're right that sitting down at a table doesn't bind you to a contract, unless there has been an explicit acceptance of the terms that were explicitly offered by the other party. FIDE rules require that this happens before the game starts, of course, so that failure to appear results in forfeiture.
Anyhow, to your subject line, contracts are only for people, but that doesn't mean that people can't delegate to machines such that those machines can accept terms on behalf of the user. This holds for all systems, REST based or not. REST just has a way of presenting and accepting contracts (present offer over GET response, accept offer with POST request), whereas Web services does not.
Contracts are for people, not things
I don't think I missed the point at all. The author's point was that if you telnet to port 80, you expect a machine to communicate via the HTTP protocol. This is fundamentally wrong and fundamentally what's wrong with the REST proponents' argument. Port 80 is just a socket. Port 80 is not bound to HTTP and HTTP is not bound to Port 80. It's just a convenience that the REST crowd wants to enshrine as some sort of Platonic ideal.
Contracts are for people, not things
Not true; Port 80 is bound to HTTP.
From http://www.iana.org/assignments/port-numbers:
Ports are used in the TCP [RFC793] to name the
ends of logical connections which carry long
term conversations. For the purpose of
providing services to unknown callers, a
service contact port is defined. This list
specifies the port used by the server process as
its contact port. The contact port is sometimes
called the "well-known port".
[...]
http 80/tcp World Wide Web HTTP
http 80/udp World Wide Web HTTP
HTTP and Port 80
I am well aware of the fact that Port 80 is assigned to the http protocol by IANA. Read your own post. "For the purpose of
providing services to unknown callers". If you are not interested in providing services to unknown callers, you are not bound to use port 80 for http. The port assignments issued by IANA are very useful, but they should not be enshrined as some sort of Holy Writ.
SOAP does play chess - it just doesn't use all of the pieces
SOAP's use of HTTP is respectful of the spec (a.k.a. Chess) in that POST imposes the least restrictions wrt idempotency and cachability.
Granted, few if any SOAP apps take advantage of other HTTP methods when an operation is known to be idempotent and/or cachable.
Contrast this to the multitude of apps that use GET when submitting a form that mutates back-end state.
As SOAP is adopted on other transports (e.g., beep, jabber, smtp), one has to wonder whether it's sensible to pollute the web service model with HTTP-isms that were designed for HTML-based hypertext applications.
SOAP does play chess - it just doesn't use all of the pieces
I agree that the SOAP *spec* is respectful of HTTP (at least SOAP 1.1 and 1.2 are, SOAP 0.9 and 1.0 were not). But I disagree that people's use of SOAP is respectful, which is what the chess/checkers analogy was about.
You see, SOAP bound to HTTP *is* HTTP (chess is still chess), while SOAP bound to SMTP *is* SMTP. SOAP is a chameleon, while most people use it as if it were its own layer.
Firewall's fault
This "playing checkers with a chess set" behavior is frequently due to the fact that firewalls often block all outgoing ports except port 80. Or they may block some ports, but port 80 is always left alone. Application developers have therefore been forced to design their protocols to use port 80, because that's effectively the only port that their protocol is guaranteed to work on, through most firewalls.
online chess
And I'd rather play chess online at online chess :)