(OT) URL Pipes

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:

Search with no parameters returns all customers
Set the f_name attribute on all of them to "bob"
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.

Cheers,
Ovid

New address of my CGI Course.

Comment on (OT) URL Pipes

Replies are listed 'Best First'.
Re: (OT) URL Pipes by brian_d_foy (Abbot) on Nov 29, 2005 at 02:20 UTC
I used to do a lot of that sort of thing, but never to modify the data. Mine looked more like: `/rest/customer/search=bob/sort=date/format=xml/email=address` [download] I never really used it much since customers weren't keen on the idea. We ended up just making a button with text entries for each of their common tasks. -- brian d foy <brian@stonehenge.com> Subscribe to The Perl Review	[reply] [d/l]
Re: (OT) URL Pipes by demerphq (Chancellor) on Nov 29, 2005 at 13:30 UTC
We do it here. We have opcodes. Opcodes execute in a particular order before the main page renders. so for instance if you send a message and fetch the xml results at the same time the message opcode will execute before the xml fetch will. Or another example might be logging in, sending a message and getting the xml result set back. Two opcodes and a page fetch. --- $world=~s/war/peace/g	[reply]
Re: (OT) URL Pipes by Perl Mouse (Chaplain) on Nov 29, 2005 at 10:21 UTC
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. So, you want a transaction. If all your actions are done in a database, then it's easy: just begin a transaction, commit if you succeed doing all parts of your pipe, rollback otherwise. If everything happens in a filesystem, and you have a filesystem that allows snapshots on demand, it's pretty easy as well. Make a snapshot, do whatever you're doing, and if it fails halfway, restore from your snapshot. On a grander scale, if all your data is on a SAN, you might want to take a business copy. Then you suspend a copy, do your business, and either resync from the live copy or the suspended copy, depending whether there's success or failure. But without knowing more about the programs you're running, I can't suggest anything more specific. Note however that this problem of needing to be able to rollback isn't related to whether you manage to encode all the steps in a single URL. If the request would be in the body of a POST request, you'd have the same problem. Or if you'd write it in a Perl program without the web overhead. `Perl --((8:>*`	[reply]
Re: (OT) URL Pipes by steveAZ98 (Monk) on Nov 29, 2005 at 02:15 UTC
What do you see the difference being between this and using regular parameters? i.e. /rest/customer/search?f_name=bob&command=save	[reply]
Re^2: (OT) URL Pipes by valdez (Monsignor) on Nov 29, 2005 at 13:28 UTC
There is no real difference, what really matters here is the ordering of commands; in both cases you should write your own 'query' parser, since CGI.pm will not help you with this. There are many interesting articles about this topic at The Restful web. HTH, Valerio	[reply]
Re: (OT) URL Pipes by zby (Vicar) on Nov 30, 2005 at 13:26 UTC
When you change it to POST queries you'll make some text input field. You'll lose the 'editing the address field' utility of this idea. You could switch to the standard UNIX shell semantics and use some CGI shell instead of that.	[reply]


Do you know where your variables are?
	PerlMonks