I have a large Catalyst app and want to get a list of all endpoints it supports (bonus points if it can tell me if the request method). Is there some easy way to ask Catalyst to list them?
Catalyst does not know the full set of paths. The true dispatch paths are resolved dynamically, iterating through DispatchType classes until one responds favourably to a call of match.
The debug option does a one-time enumeration of all possibilities that your controllers allow. If you want to interfere with this, you have to look at Catalyst::Dispatcher::_display_action_tables
It's a tree-walking algorithm that iterates through each route it finds at '/' and follows each subsequent route that $controller->actions returns. It's not easy to read, but you could conceivably implement a version of _display_action_tables that doesn't just print to a table, but does something else instead. Then call it in the live application with $c as argument and see what happens!
Related
Usually I use paginate when I want the user to view a list (or a narrowed down list based on filters). Simple example below:
Thing::query()
->orderByDesc('created_at')
->paginate(40);
If I wanted the user to view a short list, like get the five newest models, I would create a separate api with a query like below:
Thing::query()
->orderByDesc('created_at')
->take(5)
->get();
I want to combine the two eloquent queries in such a way that it gets the paginated list by default, but will take 5 if the query param 'take=5' is present. I can do this the following way:
Thing::query()
->orderByDesc('created_at')
->when(
$request->query('take'),
fn ($query, $count) => $query->take((int)$count)->get(),
fn ($query) => $query->paginate(50)
);
The above works but has been described by a colleague as a little confusing, since the 3rd argument to when() is if the first argument is false (documentation) but that isn't immediately apparent when viewing the code. The "confusing" part might be subjective here but I would like to make sure my code is quickly understood by other devs as best as possible.
Does anyone know of a simpler/clearer or just another way to achieve this? In an ideal world the take()->get() would only exist in the when() method and paginate() would exist outside of it, but be overridden by the when() condition if true.
Note: I anticipate some people might say that they should remain as separate api's, however in my opinion the extra logic here is so simple that the gain in reduced code outweighs the gain in "do one thing well".
Let's say I want to make a RESTful interface, and I want to work with foos based upon their IDs. Nothing new here:
GET /api/foo1 returns a representation (e.g. using JSON) of foo1.
DELETE /api/foo1 deletes foo1.
etc.
Now let me tell you that a "foo" is a collection type thing. So I want to be able to add a "bar" to a "foo":
PUT /api/foo1/bar3 adds bar3 to foo1.
GET /api/foo1/bar3 returns a representation of foo1.
DELETE /api/foo1/bar3 removes bar3 from foo1.
DELETE /api/foo1 deletes foo1 altogether.
Now the question remains: what does GET /api/foo1 do? Does it it simply return a representation of foo1 as I originally assumed in this question? Or does it return a list of bars? Or does it return a representation of foo1 that is both a description of foo1 as well as includes a list of all contained bars?
Or should GET /api/foo1 merely return a representation of foo1 as I assumed at the beginning, and require a PROPFIND request to list the bars inside foo1 (the approach taken by WebDAV)? But then in order to be consistent, wouldn't I have to change all my other list-type functionality to PROPFIND, directly contradicting all those thousands of RESTful tutorials that say to use GET /api/foo1 to list the contents?
After some pondering, I think the best conceptual explanation from a RESTful perspective is that usually the "thing" is not the same thing as its "collection". So while in the WebDAV world a directory/ might be the same thing that holds its files, in the RESTful world I might have a separate directory/files/ subpath for the contained files. That way I can manipulate directories separately from the files that hold.
Consider a RESTful API for a farm which contains barns. The endpoint farm/api/barns/ might return a list of barns, one of which would be farm/api/barns/bigredbarn. Naively I would think that retrieving farm/api/barns/bigredbarn/ would provide me a list of animals in the barn, which is what prompted this question.
But really the animals in the barn is only one aspect of the Big Red Barn. It might contain vehicles and hay:
farm/api/barns/bigredbarn/animals/
farm/api/barns/bigredbarn/vehicles/
farm/api/barns/bigredbarn/haybales/
With this approach the dilemma I faced does not arise.
The semantics of webdav has never really been reconciled with the idioms of RESTful interfaces.
In theory, GET should retrieve a representation of a state of a resource and PROPFIND should be used to retrieve the members of a collection.
So you should do this:
GET /api/foo1/ - returns state of foo1 only
PROPFIND /api/foo1/ - returns the members of foo1
Most front end devs would freak out if you told them to use PROPFIND, although its completely supported in browser js implementations.
Personally i use a webdav/json gateway, where requests are made using RESTful idioms, but routed to my webdav implementation
For example i would do this:
GET /api/foo1/_PROPFIND?fields=name,fooProp1,fooProp2
And that would return
[
{ name : "bar1", fooProp1: "..", fooProp2 : ".."},
{ name : "bar2", fooProp1: "..", fooProp2 : ".."}
]
One advantage of this approach is that client's get to control the json properties returned. This is good because a rich API will have a lot of properties, but in most situations clients dont need all of them.
The routes and their operations in RESTfull API are completely designed by the developers. It's the developer who decides what to return while requesting a specific route say, GET /api/foo1.
And the developer should design every route including /api/foo1/bar. There is no specific rule on what a particular route should do. If your API is an open-source project make a clean and clear documentation of every route.
Don't waste your time thinking about the old school strategies.
Reading http://search.cpan.org/~ether/Catalyst-Manual-5.9009/lib/Catalyst/Manual/Tutorial/02_CatalystBasics.pod I see $c->stash(template => 'hello.tt');.
There is a template, but where is the view? Why is the view not specified explicitly?
Also: How to call a view explicitly (not by the template name)?
This can be a little tricky because it is a combination of extremely flexible and plain DWIW. The .tt in the template name indicates that Template::Toolkit is the presumptive default. It's not necessary to use this View at all but it is used in most of the documentation.
You can render whatever is in your stash/$ctx by forwarding to a view: $c->forward($c->view("JSON")); for example, or you can decide for the rest of the request cycle like this $c->stash( current_view => "CSV" ). You have to have the view(s) installed and configured in your application, of course. You can also use views directly-
my $body = $c->view("Xslate")->render($c, "folder/email_template.tx", $params);
A tricky part becomes what your end method(s) will do.
The generally recommended default is Catalyst::Action::RenderView. It is smart (and flexible if you want to change its behavior). If you have set a redirect, for example, it won't render a page, it will just do the redirect. If you have already generated $c->response->body content it will also "just stop" and trust that what you've already done is what you wanted.
There is enough complexity in the flexibility that I really recommend just putting together a toy app run in the restarting dev server and trying out all the things you want to understand better. None of it is that hard in itself but it all adds up to confusion unless you break it down into digestible chunks.
My rules in a drl file will return 1 or more String values back to the calling program.
Right now the way I do that is via global variables as below
global java.util.List<String> statuses;
The calling program will pass it an empty ArrayList() and within my rules, I'll add the String values into the List. Finally, my calling program will retrieve the statuses list that might contain zero or many String items in the list as below
session.getGlobal("statuses")
But in the drools user guide, it said that it's not recommended that rules should change values of the global variables.
Are global variables the best way to return values back to the calling program? If not, what's the best way please? I have to deal with concurrency in my web application as well so I'm looking for the best way to return values back to the calling program for concurrency as well.
Thanks
There is nothing wrong with changing the value of a global variable in the code within the consequence ("right hand side") of a rule. What you describe is one of standard use cases for globals.
What the author of the Drools user guide (please add the exact reference!) meant is that changes of a global that is used in the condition ("left hand side") of a rule are not considered in the (re-)evaluation of these conditions. Therefore, this is to be avoided.
As for concurrency: Use a properly synchronized List object as a global.
I have seen the examples of Net::OpenID::Consumer::Lite on CPAN but I was hoping to get a single script that uses POST method. If nobody has this than I will post my solution back here once I get it working.
This seems to be the only applicable test in the manifest and it doesn't seem too useful
http://cpansearch.perl.org/src/TOKUHIROM/Net-OpenID-Consumer-Lite-0.02/xt/001_mixi.t Apache2::AuthMixi also uses it a bit
This module simply delegates to LWP::UserAgent. I don't like it, it should subclass LWP::UserAgent instead of delegating. You can find the docs for LWP::UserAgent on cpan, and access the base copy through the hidden method _ua (though, by convention, the preceding underscore tells you it isn't supported and it is supposed to be kept secret)
my $csr = Net::OpenID::Consumer::Lite->new();
$csr->_ua->post(); # same as LWP::UserAgent::post()
It seems as if you're supposed to use only handle_server_response() which calls _check_authentication() which calls _get() which delegates to ->_ua->get().
check_authentication() wants an HashRef jump-table with 5 events for not_openid, setup_required, cancelled, verified, and error. In addition I believe it wants a bunch of key (openid.) prefixed stuff, and values.
Per the code, for a request to be sent $request->{'openid.mode'} must exist in the $request and be set (preferably to) check_authentication, and not set to 'cancel'. The openid.user_setup_url key must logically not be set or it will just call the respective callback. It must also have an op_endpoint.endpoint key set, which is where the request is destined to go.
This code isn't hard to read, I'd suggesting taking a look The author also seems to have a bunch of modules which is a good sign. I don't like jump-tables with data like that, it seems kind of weird from a UI perspective.