Timothy Appnel wrote:
> On 1/2/07, Michael Peters <[EMAIL PROTECTED]> wrote:
>
>>> First off, I would like to allow users to be explicit or just use
> convention. So
>> you could have a rule like this:
>>
>> '/app/:module/:rm' => { auto_rest => 1 }
>
> This is goes to where I said "There is one area I'm unsure of though
> -- should the mixing of REST-enabled and "standard" application
> modules be permitted by Dispatch or should a developer be forced to
> choose one direction or another?" in my initial post to this thread.
>
> My instinct is that RESTful app modules and "standard" application
> modules shouldn't be mixed.
I disagree. There are lots of reasons to mix. You're adding a new
sub-application to an existing application and you want to use REST; You're
adding a new REST API (think google) but it's not the application itself; You're
transitioning to a REST based approach one piece at a time.
> There should be a "master switch" for
> those who are buying in to REST rather then a per runmode/rule.
Well, the 'auto_rest' flag would be global (defaulting to 0) and could be
overridden on a per-rule basis.
> Still
> I could see someone working this style into an existing application
> suite over time. For that I was thinking the ability to check for a
> "methodless" runmode could be supported. For instance GET /people
> would look for people_GET and if that doesn't exist look for just
> people.
I'm not sure I like that much magic in the dispatching.
> Perhaps a global parameter to control REST support with three values
> -- strict, transitional and none? none would be the default in which
> Dispatch would operate as it has and NOT append the HTTP method.
> transitional would first look for a method in the application module
> with the appended HTTP method and then without if that is not found.
> strict would look for the runmode with the HTTP method appended and
> return an error if its not found.
I prefer just 2 values, true or false. And then you can mix them however you
want.
>> And it would append the HTTP method name (lowercased?) to the run
>> mode. So
>
> The HTTP methods are formally uppercased. Most browser will accept it
> regardless of case. I like uppercase because it makes it easier to
> grok what is part of the REST convention and what's my method name.
Yeah, I think I'll just make it a preference.
>> And if a method is attempted for which there is no run mode, then it
>> would be
>> the normal rm-not-found thing.
>
> In terms of REST a 400 BAD REQUEST status should be returned, not a
> 200 OK with an HTML error message which so many of us (me included)
> tend to do.
Glad to know that. I'll have Dispatch DTRT.
>> Next, I'd like to allow users to be explicit in HTTP method mapping:
>>
>> '/app/:module/stuff[get]' => { rm => 'get_stuff' }
>
> Like I said I'm not sure mixing styles is a good idea for reasons of
> simplicity and clarity, but if it were explicitly supported I'd rather
> see something like...
>
> '/app/:module/stuff' => { rm => 'get_stuff', http_method => 'GET' }
That approach won't quite work. URL dispatching is based on the 'rule' (the left
hand side) and when a decision is made then the 'args' (the right hand side) is
used to provide extra flexibility. Putting the 'http_method' on the right hand
side would mean that after matching the rule we'd still need to check the args
to make sure we can use the rule. All the decision making information should be
contained in the rule itself.
We need to support rule groups like these
'/:app/:rm[get]' => { rm => 'get_stuff' },
'/:app/:rm[post]' => { rm => 'add_stuff' },
'/:app/:rm[delete]' => { rm => 'delete_stuff' },
Any other thoughts on syntax?
--
Michael Peters
Developer
Plus Three, LP
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
