Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday November 28, 2005
09:19 PM

URL Pipes

[ #27780 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 i
    • 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