As Jon Udell pointed out in his Perl conference talk, the UPS form was probably the first major example where a company used the web to "open up its business procedures to its customers."
But the form is merely:
<FORM METHOD="POST" ACTION="http://wwwapps.ups.com/tracking/tracking.cgi"> Tracking Number: <INPUT TYPE="TEXT" NAME="tracknum" SIZE="40"> <INPUT TYPE="submit" VALUE=" Track "> <INPUT TYPE="reset" VALUE="Clear"> </FORM>Therefore, the front-end form and back-end process can reside on different machines. Here, rather than link to UPS's form, I'll just embed it right in this document: More than that, the form can be dispensed with entirely. Unless the CGI application explicitly depends on method=POST, a URL can directly pinpoint the information for any package. A URL can drive a process. Thus, UPS was not only opening up its business practices to its customers, but also publishing an implicit API (hmm, "the UPS software developers kit"??). For example: http://wwwapps.ups.com/tracking/tracking.cgi?tracknum=1Z742E220310270799
"Every package has its own home page on the web!"
The mere act of clicking this URL fires off an email. Scary!! (Though the key point for this talk is that the ability to construct such a URL, with such a "side effect," illustrates how URLs are APIs -- even if the web designer never thinks of them that way.)
There are many such unintentionally-open APIs on the web. For example, do an AltaVista search for "mail_form". Almost every one of the listed pages has a general-purpose email facility, even though the web designer probably didn't intend this.