I’ve been reading and thinking a lot about REST lately. There’s a good high-level intro to REST here, here, and (of course) here. I suppose part of my interest in it stems from my recent projects at work. I was part of a team that exposed a bunch of our product’s functionality as a brand-new SOAP API. What struck me was how complicated it all is. It’s supposed to be a simple way to use standardized formats to enable an RPCs across and among disparate technologies, and for the most part, it delivers (Idiosyncrasies like getting a .Net SOAP client to pass dates to a Java SOAP servers, and vice versa, in different timezones, with null dates, notwithstanding). But the steps involved in creating the service, exposing it, generating the WSDL, embedding that WSDL in the deployed war file, then getting the clients to generate stubs from those WSDLs and making it all work… well, it’s cumbersome. More cumbersome than it oughtta be. Full disclosure – my only exposure to creating SOAP web services is through Apache Axis. I’ve heard that CodeHaus’s XFire and even .Net are easier to work with.
So reading about RESTful services was like a breath of fresh air. Now, every article I’ve ever read says that REST does not necessarily need to use HTTP as its transport protocol, but then they invariably proceed to discuss how HTTP’s GET, POST, PUT, and DELETE commands map really nicely to the ubiquitous CRUD database operations, and explain how to implement REST on HTTP. But I wonder if it wouldn’t make just as much sense to implement a RESTful service on FTP. Why not? The “resources” in both cases are basically file pointers. You could do get, put, and delete, and navigate through the hierarchy of resources with cwd. For transferring large files, the FTP protocol might actually be better suited for the task. So, e.g., let’s say you have a DSS application where you’re transferring large batches of data to a data warehouse from an OLTP database. Why wouldn’t this be a perfect situation for creating a RESTful service over FTP?