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. Ideally, I would like to just add the plugin, and magically get a new route that tells me all the available routes and their params and whether or not those params are required or optional, etc. I looked at the source code for Dancer::Plugin::SiteMap and have already modified it to basically do what I want it to do. It writes out all the routes in JSON format. I have to add the params validate code (I am going ahead and using Params::Validate as that seems to be highly rated). If the plugin ends up being not-too-rough, I would like to release it so perhaps someone else can use it or improve on it. Which brings me to an associated question -- when I get to the point where I can release this modified version of D:P:SiteMap, should I release it as a different plugin? It is clearly generously inspired by that plugin, but is aspiring to do something a bit different. What would be the right thing to do?
Daniel
From: "Mr. Puneet Kishor" <punk.kish@gmail.com> To: dancer-users <dancer-users@perldancer.org> Date: 30/09/2011 14:51 Subject: [Dancer-users] a REST question immediately followed by a Dancer-implementation question Sent by: dancer-users-bounces@perldancer.org
So, I have a lot of methods such as get '/foo' => { .. }; get '/bar' => { .. }; get '/baz' => { .. }; get '/qux' => { .. };
All the above methods are reachable via a browser in which they depict some visual representation of the data.
Most of the above methods have their '.:format' counterparts, mostly returning JSON packets when reached either via the browser or via the command line.
All the methods above return something by default or modified by parameters. So, "http://server/app/foo" may work, or may require some parameters as in " http://server/app/foo?age=27&before=yesterday&for=rascals"
I would like to implement a "meta" method, say
get '/rest' => { .. };
which should return a listing of all the methods above, along with their parameters, if any, and whether those parameters are optional or required.
http://server/app/rest {"resources": [ {"name": "foo, "params": [ {"required": [ {"name": "age", "type": "int"} ]}, {"optional": [ {"name": "before", "type": "string"} {"name": "for", "type": "string"} ]}, ]} ]}
In other words, this meta method returns all the resources available at the http://server/app.
Of course, I could code this for each app, but it would be nice to automate it.
Suggestions? Ideas?
-- Puneet Kishor