Web Service Tools
Okay, some continuing thoughts about Web Services as Unix-like Software Tools. Les just left a message about STDIN/STDOUT/STDERR which made me realize I forgot about STDERR. That's important to remember because Unix tools can take in a chunk of data and send it out the other side, and also give you messages about what's happening all at the same time. The web just has request/response by default, so we'll have to come up with where to put that third channel. But let's put that aside for a sec and look at the other analogies:
1) The Endpoint is the App. So what I'm saying here is that just like grep does one thing and one thing well, an Web Service Tool should be the same way. http://example.com/tools/grep for example, would just process text the same way that grep does it. Grep doesn't try to be a universal editor or RegEx library or whatever, it just does it's one thing and does it well.
2) The Params are the Options. Almost all Unix tools have a host of options that can be passed to the app along with STDIN. Using our grep analogy, it would look something like this: http://example.com/tools/grep?extended-regexp=true&word-regexp=true&invert-match=true. Who knows, maybe these params would include URLs for other resources (like the --file option).
3) STDIN is an HTTP POSTed stream of data (or null if using GET), STDOUT is the HTTP Response. I was stressing XML before, but maybe that doesn't have to be the case. Say you wanted to have a Web Service Tool make a thumbnail of an image? Well, you post the file to the tool, with params, and get your result back. Though I think XML is what's going to provide the highest level of interop for most things, at the base level, it doesn't have to be.
4) Piping and STDERR are provided as URLs to other tool endpoints. Here's where the easy analogies stop, I think. There needs to be a place for STDERR to go and there needs to be a way to pipe the STDOUT results to another tool. It seems to me that both are simply additional URL endpoints, but the implementation of this is the part that's sketchy.
Where is a good place to put those URLs for the tool to get to them? Hmmmm. The simplest place would be in the params. But that would create long and ugly GET strings. Not that the traditional command line doesn't get ugly, but we wouldn't have a $PATH to help us cut the length down. Ooh - unless there was a central repository of endpoints out there... like a DNS system for Web Tools. Or like Les said, a TinyURL type system. Neat idea, but for another post. The other place is within the POST itself. Like the Atom API is currently doing, they could go in custom headers: X-STDOUT and X-STDERR headers could provide URLs where the Web Service Tool would POST the results to. This seems the most flexible since, like I said in anology #3 above, the data being sent doesn't have to be XML, which would prevent having a custom XML envelope or something.
Actually, now that I think about it, having the URLs in both the params or the headers would be fine, and the tool just has to look in both places with the params overiding the headers (which would make it great for testing, etc.).
Cool! So there you go. Web Services as Unix Software Tools. If I was feeling energetic I'd whip up an example or two. I do have one reservation. I like all that above since it parallels with Unix so well, however I wish that XML played a bit more of a role since I think that's where the interop is really going to come to fruition. But maybe this model is more flexible and simple, which is really the Unix way. XML can be relegated to the Application level in all this and not lower in the OSI model...
Okay, thoughts welcome. I'm already thinking up edge cases already - like why not have STDIN be an optional overriding param as well so you can just use GETs everywhere and would enable "sideloading" type functionality as well? This would be cool to enable use of the tools from something as simple as a mobile WAP browser, right?
Cool stuff... anyone grok what I'm getting at?
-Russ