Why Vertx doesn't allow query parameters based Routers

[Manish Kumar]

Vertx only allows defining routes/handlers based on path, not based on query parameters.

I am wondering if it's intentional. Due to nature of our product, we receive most of data variables as query, and request has to be handled accordingly.

Of course we can do IF/ELSE check and call methods from different handlers, we are just trying to understand the reasoning behind the limitation in Vertx Routes.

We are open to create a PR if you all thinks it will be a good value add in Vertx.

~Manish

[javadevmtl]

You don't need to specifically specify anything for query parameters...

Define your route as usual....

router.get("/somePath")
        .handler(this::doV1);

Handle the request...

public void doV1(RoutingContext rc) {

    MultiMap queryParams = rc.request().params();

    String param1 = map.get("param1");

    rc.response().end();

[Manish Kumar]

This isn't what I need. We want to define different handlers based on query parameter.

e.g.

router.get("/somePath?command=ABC").handler(this::myABCHandler);

router.get("/somePath?command=XYZ").handler(this::myXYZHandler);

If you notice, my path remains same. For us, query parameters defines the different flows. I hope you don't suggest us to use different paths instead for query parameters because it's not something in our control because our product server as an API to another and we have to deal with what we have got.

[ad...@cs.miami.edu]

You could do something like the following sudo code

router.get("/somePath?command=ABC").handler....

if (params["x"]==y) {
so something
} else if (params["x"]==z) {
do something...
} else {
do default
}

While the above might not be what you are looking for, it is really not too much more code (might be less) and will be easily understood by just looking at the code.

-Adam

[javadevmtl]

Your path will stay the same. The vertx rc.request().params is a multimap and can have as many query params as you need...

Think of query params as implicit. And path params such as /somepath/:somevalue as explicit.

If you want to hardcode /somepath?command=xyz might as well just use path params.

And honestly defining a bunch of routes mapped to specific query params values, is no sexier than if else or switch.

[Jez P]

It is  intentional. Query params are supposed to be dynamic so you're expected (as you would be in just about any other web framework) to handle the values internally, starting from a single handler. 

That said, you could just map command values to your own handlers based on command name via a map <String, Handler<RoutingContext> which would give you the effect you're after. 

[Manish Kumar]

Yes we could do that, but imagine having 20 if/else check. I think same was the reason to have the ability to define Routes for path, so that these if/else could be avoided. Otherwise path could be handled the same way as your suggestion.

I know that not many people needs Route handlers based on query param, but for us it's a valid use-case, and that's why I wonder what was the reason Vertx didn't allow defining routes based on query params (or matching query params in RegEx based paths).

[Manish Kumar]

Yes we could do that, but same could be done for path handling as well, we would never need to have Route handlers for path either.

We use frameworks/toolkit so that these small but important things could be avoided (or abstracted/hidden). I know it's not too much for me to implement the way you suggested, but I hope you understand my point as well.

I agree that query params are dynamic, but I have seen many software/apps that relies on query params to define their handlers (of course not the REST API but most of them webapps etc).

[Thomas SEGISMONT]

With JAX-RS it's the same, query parameters don't participate in route matching, on path params do.

If you want something simple and scalable, you could register handlers in a map. Like:

query param A => handlerA

query param B => handlerB

Then when the request comes check if a key in the map is present in the query params. Stop at first match and invoke corresponding handler.

No if/else and no code to update when adding query param / handler pairs.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/081baf81-e38f-433f-a803-e8f84daea561%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Julien Viet]

with Java 8 you can use the switch statement on a String to make it more readable.

-- 
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/8bfefc4b-eb69-4e26-9c7a-288014f10680%40googlegroups.com.

[ad...@cs.miami.edu]

>> Yes we could do that, but same could be done for path handling as well, we would never need to have Route handlers for path either.

When frameworks/toolkits are developed, the designers need to prune the options, else the framework would become too "big".  In this case, vertx does not have the exact feature you want, but it does have a simple mechanism to accomplish the stated goal (path route + internal if/else or switch).   I have frequently used internal if/else to handle route type functionality and it works pretty well.

-Adam

[Jez P]

I understand your position, but equally my view is that web frameworks shouldn't in general support such abuses. I bet the apps you mention are not built on frameworks which behave in the way you suggest vert.x should. Certainly none of the major Java web frameworks do, as far as I'm aware. 

You're ignoring the fact that this approach is fundamentally more complex than path parameter matching (and the key difference between path routing and hardcoded query param routing is that what happens if you have two values in the same query parameter for example? This is legitimate according to HTTP spec - which handler do you route to? Example http://localhost?command=cmd1&command=cmd2 -> entirely legitimate query) In short your approach adds complexity, especially as query parameters can be added dynamically as well. So I would argue against this. 

[Manish Kumar]

and hardcoded query param routing is that what happens if you have two values in the same query parameter for example? This is legitimate according to HTTP spec - which handler do you route to? 

@Jez -  This is a very valid point, and I am now convinced that it's better to do some internal routing mechanism than supporting parameters based routing support in framework/toolkit itself. Thanks a lot for your time guys!!!