REST on WebSh

[Mi...@frogware.com]

I'm thinking about building a web app using a REST-style architecture. I 
can send links if anyone's interested, but basically REST is a style that 
tries to take advantage of web architecture and infrastructure. REST has 
some mandates/best practices. Among them is the fact that resources should 
be uniquely named, and that database CRUD operations should be mapped to 
HTTP methods:

 * Create = POST
 * Read = GET
 * Update = PUT
 * Delete = DELETE

also:

 * Select = GET + query string

REST mandates that, in general, actions should *not* be sent in query 
strings.

I've been looking at WebSh for a couple of days. It looks like a great 
tool. WebSh seems to prefer, though, a single URL for a script, and seems 
to prefer that command names be passed as query string params. If no 
command name is given, everything goes to the generic "dispatch" proc.

So it seems, on the face of it, that it's nearly possible to use WebSh for 
this, but it doesn't line up with WebSh's design. For example, I'm not 
sure that WebSh can do arbitrary URLs, and if it does it looks like you do 
your own dispatching. Not fatal, but obviously not what's intended.

Here's a small example of how REST would work. Let's say there's some kind 
of billing system. It has a root:

        /billing

When you GET that page you get an XML doc with xlinks to the next level 
(among, perhaps, other things):

        /billing/customers
        /billing/invoices

When you GET /billing/customers you get an XML doc with xlinks to 
customers; query-string params would produce a filtered/ordered/etc list.

To find out about a particular customer--say, customer 01125--you'd GET 
/billing/customers/01125, which would again return an XML doc.

To update that customer you'd modify the XML doc and PUT it back to that 
URL, and to delete the customer you'd DELETE that URL.

To create a customer you'd POST to /billing/customers, which would return 
an XML doc with a new customer ID. You could then PUT to the URL.

Part of the idea behind REST is that doing things this way uses the full 
power of the web to cache, filter, proxy, protect, etc. (WebDAV would even 
provide a locking model.) There are some issues with REST to be sure, 
but... I'd like to try it out.

So, again: is this a very bad fit for WebSh?

---------------------------------------------------------------------
To unsubscribe, e-mail: websh-user-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-user-help@tcl.apache.org

Re: REST on WebSh

[Ronnie Brunner <ro...@netcetera.ch>]

There are certainly ways to map this to Websh.

The question would be if you want to write your own command
dispatching or use Websh's dispatching, but w/o using the query string

Something like

 set method [web::request REQUEST_METHOD]
 web::dispatch -cmd $method

would allow you to write commands for each method

 web::comand GET {
  # your get stuff here
 }

 web::command PUT {
  # your put stuff here  
 }

You can also access [web::request PATH_INFO] so you know what you want
to do (get the command parameters)

I haven't ever tried to play around with other methods than GET and
POST, so I on't really know if they work or if the above approach
makes much sense ... (note that depending on the syntax of UPDATE,
PUT, and DELETE methods, Websh's handling of POST data might not work 
and that would leave you with parsing stdin manually, which you can do
if you dispatch with the -postdata string "" option (dispatch will now
ignore stdin). But that would cetrainly be painful and not Websh-like.

Don't know if that helps ...

Regards
Ronnie

> I'm thinking about building a web app using a REST-style architecture. I 
> can send links if anyone's interested, but basically REST is a style that 
> tries to take advantage of web architecture and infrastructure. REST has 
> some mandates/best practices. Among them is the fact that resources should 
> be uniquely named, and that database CRUD operations should be mapped to 
> HTTP methods:
> 
>  * Create = POST
>  * Read = GET
>  * Update = PUT
>  * Delete = DELETE
> 
> also:
> 
>  * Select = GET + query string
> 
> REST mandates that, in general, actions should *not* be sent in query 
> strings.
> 
> I've been looking at WebSh for a couple of days. It looks like a great 
> tool. WebSh seems to prefer, though, a single URL for a script, and seems 
> to prefer that command names be passed as query string params. If no 
> command name is given, everything goes to the generic "dispatch" proc.
> 
> So it seems, on the face of it, that it's nearly possible to use WebSh for 
> this, but it doesn't line up with WebSh's design. For example, I'm not 
> sure that WebSh can do arbitrary URLs, and if it does it looks like you do 
> your own dispatching. Not fatal, but obviously not what's intended.
> 
> Here's a small example of how REST would work. Let's say there's some kind 
> of billing system. It has a root:
> 
>         /billing
> 
> When you GET that page you get an XML doc with xlinks to the next level 
> (among, perhaps, other things):
> 
>         /billing/customers
>         /billing/invoices
> 
> When you GET /billing/customers you get an XML doc with xlinks to 
> customers; query-string params would produce a filtered/ordered/etc list.
> 
> To find out about a particular customer--say, customer 01125--you'd GET 
> /billing/customers/01125, which would again return an XML doc.
> 
> To update that customer you'd modify the XML doc and PUT it back to that 
> URL, and to delete the customer you'd DELETE that URL.
> 
> To create a customer you'd POST to /billing/customers, which would return 
> an XML doc with a new customer ID. You could then PUT to the URL.
> 
> Part of the idea behind REST is that doing things this way uses the full 
> power of the web to cache, filter, proxy, protect, etc. (WebDAV would even 
> provide a locking model.) There are some issues with REST to be sure, 
> but... I'd like to try it out.
> 
> So, again: is this a very bad fit for WebSh?
> 
> To unsubscribe, e-mail: websh-user-unsubscribe@tcl.apache.org
> For additional commands, e-mail: websh-user-help@tcl.apache.org

----------------------------------------------------------------------
Ronnie Brunner                             ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich   phone +41 1 247 79 79 fax +41 1 247 70 75

---------------------------------------------------------------------
To unsubscribe, e-mail: websh-user-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-user-help@tcl.apache.org