[Dancer-users] a REST question immediately followed by a Dancer-implementation question

[Puneet Kishor]

My earlier response was too much of the "shot from the hip" variety. Here is a little bit more thought --

On Sep 30, 2011, at 11:32 AM, Mr. Puneet Kishor wrote:

> On Sep 30, 2011, at 11:21 AM, Daniel Perrett wrote:
> 
>> You want code which will infer what your code is requiring? Sounds tricky, 
> 
> Perhaps.
> 
>> and I doubt you want to run some sort of meta-parser every time someone 
>> visits '/rest'.
> 
> Why not? Without any basis for saying so, I would assert that it wouldn't be very expensive. All depends on how complicated this meta-parser ends up being.
> 
>> 
>> Wouldn't it be easier to write the "resources" data structure (as you have 
>> below),
> 
> Not necessarily easier, because ...
> 
>> maybe as a config file, so you know what your application's 
>> interface is, and use that to a) generate responses to /rest, b) maybe 
>> generate some documentation, (especially if you include that in the data 
>> structure), and c) validate your parameters in the methods, e.g. creating 
>> a hash(ref) guaranteed to contain all those and only those parameters 
>> specified in the config (and using that hash(ref) thereafter instead of 
>> Damcer's parameter function), and then you can guarantee your code 
>> complies with the specification.
> 
> 
> for the simple reason that my "config" file and my application interface will quickly get out of sync (unless I generate one from the other, which is the same as running the meta-parser). Besides, I am writing the app... writing the interface would double my work.
> 
> If I look at my app code, I can see the interface, so I should be able to infer it programmatically as long as I don't get too ambitious.


Getting the routes themselves is easy. The trick is getting the params, and whether not they are required, and what kind, yadda yadda.

If I use Params::Validate, that module tells the user all this info. So, perhaps one approach would be to 

1. get all the routes (easy)
2. run all the routes one by one
3. trap the errors from Params::Validate and add them to the routes definitions
4. send the routes definitions with the associated messages from Params::Validate back to the user

Comments? Suggestions?

--
Puneet Kishor