Routing issues

[scotticles]

I use name routes, trying to create a dynamic one and running into troubles:

nested route
$api_auth->get('/getSearch/:tenant_id/:searchby')->to(controller => 'Controller::API', action => 'getSearch');

my url I am trying to do
https://myurl.com/api/getSearch/1/byid?value=1&limit=1

It makes it to the getSearch subroutine, but it will not see the limit param, it does see the value=1. I have tried a few things but i cannot seem to make it accept the &key=value that would be in a GET request.

[christopherraa]

Hi there. Based on your example I suspect that the fault lies not in the route definition but somewhere else. Unless you do anything in particular with the request parameters in the request processing the endpoint should see them exactly the same. As far as I know there are only a few that are handled by the framework specifically, like format, which might give some interesting side-effects in some scenarios.

In your particular case I would go through the request flow step by step and see if the variable is tampered with somewhere (a route hook perhaps?). In addition I would make sure that the originator of the request construct the url correctly. Like, try it using curl or something so you are certain that the request has been performed correctly. Also be mindful to add the correct parameters if you initiate any redirects as part of the request processing.

[scotticles]

Well i figured it out, it wasn't mojolicious at all, i was doing curl to test this with and apparently because & is special character i needed to wrap it in '';

curl -s -H "X-API-Key: 1234" https://mydomain/api/getSearch/1/byid?value=1&limit=1
to
curl -s -H "X-API-Key: 1234" 'https://mydomain/api/getSearch/1/byid?value=1&limit=1'

[daleif]

Ahh yes, that would of course be a problem. We've propably all been there. I already had a project opened and just tested in a browser.

[scotticles]

my fault, i dont use curl enough. i caught it when the output of my curl was missing the limit=1.

[daleif]

Once working, the URL + filtering works really well. I have it in one of our own data provider APIs

[daleif]

Try this

    $auth->get('/getSearch/:tenant_id/:searchby' => sub ($c) {
	say $c->param('tenant_id');
	say $c->param('searchby');

	say $c->dumper( $c->validation->input );	
	return $c->render(text => 'foo')
    });

the URL parameters you can access as param values, the rest are seen in the same vain as form data, aka in the validation input.

Note that if possible, it is a good idea to add patterns to the URL parameters, then users will get a 404 if the values does not match the pattern.

AFAIK there are also URL parameters that "take the rest", but the "?..." stuff has special meaning, so not sure if it would catch it.

[guest20]

Would url_with do the thing you're looking for?

mojo/lib/Mojolicious/Plugin/DefaultHelpers.pm

Line 874 in 4dae171

=head2 url_with

[daleif]

Isn't that the other way round regarding the OPs question? They had issues getting the correct data in (here due to & being interpreted by the CLI).

url_with is for generating that kind of URLs.

[guest20]

I was responding this part of your post specifically:

AFAIK there are also URL parameters that "take the rest", but the "?..." stuff has special meaning, so not sure if it would catch it.

... but I forgot to include the quote

[daleif]

Again I think you're pointing the wrong way. Yours is generating a URL with parameters, I was talking about eating up and incoming GET request and getting the ?value=1&limit=1 unparsed.

As far as I remember there is a routing parameter type that can catch everything, might be this one, https://docs.mojolicious.org/Mojolicious/Guides/Routing#Wildcard-placeholders, but not sure if that catches the ?value=1&limit=1 unparsed. Probably not