All the Perl that's Practical to Extract and Report

URL Pipes

Ovid on 2005-11-29T02:19:09

My boss has an idea which is rather interesting though I'm concerned about the implications. Essentially, he wants to be able to execute multiple actions with a single HTTP request via a mechanism similar to piping in UNIX.

Imagine a URL path like this:

/rest/customer/search*f_name/bob*save

The basic ideas is this:

  1. Search with no parameters returns all customers
  2. Set the f_name attribute on all of them to "bob"
  3. Call "save" on all of them

While I think this idea is rather interesting, I have some reservations. First, this is a GET request altering state on the server. Changing it to POST is trivial, so we'll ignore that.

My main concern is ensuring that unexpected behavior doesn't crop up. For example, if the third step of a four step pipe fails, what should be the behavior? Roll back and just give a nice error message? If so, I'll have to ensure that this behavior finds a way to "mark" anything with irreversible side-effects or simply identify and disallow them. And whatever gets used as the pipe character will need to be correctly escaped for all non-piping instances of it.

In any event, while I see the potential utility, the idea of mapping multiple actions to a single request via HTTP seems a bit odd and I'm curious to know if anyone has tried anything like this and if they can discuss the pros and cons. (Heck, discuss 'em even if you haven't tried this). I'd hate to get partway through implementing this only to slap my forehead and realize I missed something obvious.

not really a pipe is it?

Eric Wilhelm on 2005-11-29T08:43:47

It sounds like this will be a lot more like a map() than a shell pipe, but you might have the same error-checking problems. The trouble with pipes in a front-end is that the only way to get an error message from "a" to the user in a|b|c is to put it on stderr, break the pipe, and hope that b and c don't say anything confusing about the broken pipe.

So, how does that translate into your web framework? Maybe not at all. Because you have to "own" the entire process from the "search" component, you would be implementing the downstream (though there isn't really a stream) actions as function calls running within the search component. It's when you start breaking them into separate processes with only one-way communication that you run into the same problems that you would see with pipes.

So, they aren't really pipes. Right? More like for (search) {$_->f_name=bob; $_->save;} or something? I suppose you could just insist that the last step be the only state-changing action?

Re:not really a pipe is it?

Theory on 2005-11-29T14:47:04

So, they aren't really pipes. Right? More like for (search) {$_->f_name=bob; $_->save;} or something? I suppose you could just insist that the last step be the only state-changing action?

You're right, it's not like Unix pipes. It's more like chaining method calls: map { $_->f_name('Bob')->save } search();

—Theory