8 December 2006
A Case for Web Services
There are two ways to trigger code to run. Something either fits into a schedule or it happens on a flowchart. While I tend to think updating as changes occur is ideal, it’s not always possible. Take for example a closed application to be integrated with a site. The traditional way, given that neither party wants to give up control to the other, is to make a cron script run to grab a cached copy of the other’s system and do work based on it. This would be scheduled code, with all its downsides.
As distasteful as it is, for the longest time, it was the best that could happen. It would be code separated form the main site, frequently in another physical location on disk, often in another language. It would be ran as a different user in a different group. All these factors had to be accounted for and worked around. A few years ago, buzz-word named “web service” appeared. Web services, they claimed, would expose a program’s API to the public. Always coupled with talk of Java Beans and SOAP, Web service was a term doomed to the great hallway of buzzwords. Then something unexpected happened: the emergence of AJAX. AJAX legitimized at least one aspect of web services to entire legions of developers. As features are adopted in one language, others will copy and adopt it for their own use. Although AJAX is nothing more than an RPC, its implementation is so well done that server-to-server communication could use it.
Web services can nearly introduce a third way to fire code: it is not scheduled, nor is it part of a flowchart. It does induce flow charted code, much like the cron job can. But unlike the cron job, a web service can remain part of the application, exposed as an API just like web services always intended. It just took years longer for this functionality to become beneficial.