Nov 17, 2010 08:55
Yesterday, I was integrating my client's back-end with an outsourcing agent's API, and was asking the outsourcer if he had any example code. "We have some PHP, some ASP, and some CGI." The CGI turned out to be Perl-- CGI isn't a programming language, it's the most primitive API for gluing application servers and web servers together. I was surprised that he didn't have Ruby or Python, but that's how this business is some days.
The ASP code was unuseable, as was the Perl. The PHP code had some debugging code embedded, allowing me to see the format of a transaction. It looked as if the system was designed to take an HTML form off a local client's transaction and massage it into a SOAP bubble of some kind, or at the very least an XML container for the transaction.
And then I looked closer. No, it was more like a CGI stream of key/value pairs. And then I looked even closer:
It was an ad-hoc XML container for the order information, lacking either a proper DTD or XML Schema, which was then made the value of a single key/value pair, which was in turn encoded as "text/x-www-form-urlencoded" before being appended to the body of the document and transmitted.
The programmer at the server end had a CGI form processor and didn't want to muck with creating a proper STDIN handler, so he rigged up this ad-hoc monstrosity to get the entire XML document as a form value object, which he then has to unpack with another off-the-shelf XML parser.
Wow. The document has two different envelopes (three, if you count the HTTP wrapper), just because the guy at the far end has two different kinds of letter-openers.
And people wonder why I shake my head at this business some days.
geek