This is what I do in our application, using a module that we created
in-house:
my $registry = ServiceRegistry->new;
$registry->register('SERVICE1', '/api/rest/service1/{param1}/list');
my $service = $registry->find($r->uri); # $r->uri returns
'/api/rest/service1/5732/list'
print "$service\n"; # Prints "SERVICE1"
my $parameters = $registry->extract_parameters($r->uri); # $r->uri returns
'/api/rest/service1/5732/list'
print $parameters->{'param1'} . "\n"; # Prints 5732I'm just registering scalars in this example but the module allows you to register anything, including an object reference, but we store the key name of the REST endpoint that we want to hit and then use the key to pull it out of an inversion of control container. I've posted this to the list before but there didn't seem to be any interest. If this would be helpful to you, I'd be happy to send you the code. At it's core, it parses the URI and uses the keys to descend through the tree of registered services. On Mon, Aug 7, 2017 at 10:22 AM, Mithun Bhattacharya <mit...@gmail.com> wrote: > Another way to look at this is Apache has hooks for the location - that is > the URI you are requesting. Apache doesn't care whether you do a GET or a > POST/PUT to it and it is left to the underlying subsytems to manage it - > which is your case would be mod_perl. You can easily have the handler do a > if/else block based on the $r->method(). You can actually say that if > $r->method() eq 'POST' return HTTP_BAD_REQUEST or even tailor the response > to the OPTIONS request method. > > On Mon, Aug 7, 2017 at 7:26 AM, André Warnier (tomcat) <a...@ice-sa.com> > wrote: > >> On 07.08.2017 13:18, 风河 wrote: >> >>> Hi, >>> >>> for this like request: >>> curlhttp://dns-api.org/AAAA/dns-api.org >>> >>> in Dancer we could write: >>> >>> get '/:type/:domain/?' => sub { >>> >>> my $rtype = params->{ 'type' }; >>> my $domain = params->{ 'domain' }; >>> >>> >>> But in a MP handler, how could we get the similiar result, treating >>> request path as >>> GET/POST arguments? >>> >>> >> Well, fundamentally you could not treat the request path, transparently, >> as a GET/POST argument. That is precisely the kind of thing which a >> framework such as Dancer allows you to do : "abstracting" the fundamental >> difference which exists at the HTTP level (and the Apache httpd level) >> between a request path and e.g. the parameters in a query string, and make >> them "kind of look the same" to an application, using some elegant syntax. >> >> In a mod_perl handler, you would do this : >> >> my $r = shift; # Request object >> my $uri = $r->uri; # gets "/AAAA/dns-api.org" >> my ($nothing,$type,$domain) = split('/',$uri); >> >> # or, if you insist on treating the HTTP request path parts as >> "arguments" : >> my @args = split('/',$uri); >> @args = grep(!~#/#,@args); >> my $params = { >> 'type' => $args[0], >> 'domain' => $args[1], >> }; >> # (I'm sure there is a more elegant way to do this) >> >> mod_perl is not a framework. It gives you access from perl to the Apache >> internals, as they are deep down, but it does not "abstract" anything. For >> Apache "/AAAA/dns-api.org" is a request URI, it is not "GET/POST >> arguments". If this URI does not contain a "?", then the whole URI is a >> path. If it does contain a "?", then the part before the "?" is a path, and >> the part after it is a query-string, which may or may not contain key/value >> pairs which could be "parameters". Those are the underlying "apache >> objects", when apache has parsed the request. >> mod_perl gives you access to these URI, path, and query-string objects of >> apache, but it does not "abstract" them further. >> >> Dancer (and other frameworks) are different : their users want some way >> by which they can treat path components as "arguments" ? so let's provide >> them with some way of doing this, elegantly if possible. But behind the >> scenes, they do exactly as above. It's just that as a user, you don't see >> that. >> >> >> > -- John Dunlap *CTO | Lariat * *Direct:* *j...@lariat.co <j...@lariat.co>* *Customer Service:* 877.268.6667 supp...@lariat.co
