Support param in Router about vertx-web HOT 10 CLOSED

@pmlopes - Question on this. I'm not sure I really understand the purpose of param(...) - could you explain it a bit? How does it differ from the param parsing that we currently have (and that we had in vert.x 2.0 routematcher)?

from vertx-web.

the idea of the param was inspired from ExpressJS router, the way it works on Yoke is as follows, for example you have 2 routes:

GET /user/:userId
PUT /user/:userId/email

Where in the first you get the user details given the id, and in the second you update the email.

so instead of repeating yourself and in both handlers you validate if the param userId is for example a number sequence with 9 digits, your would create a extra helper method that checks if the input passes the test [0-9]{9}.

You could keep you code clean and apply the DRY approach by doing:

router.param("userId", Pattern.compile(...));

and Yoke router would call that before any route that has a param with name userId. If the test fails yoke router will return the status code 400 (bad request) and avoid further processing.

Now this is a very simple example but say that you want something more complex, that the userId context value instead of the numeric value should be the user object loaded from a database, in this case you would do:

router.param("userId", ctx -> {
// lots of validations
// going to the db...
// more validations...
ctx.put("userId", new UserObject());
ctx.next();
});

So now you seperate the concern of input validation in the param and you don't repeat yourself everywhere where you have a "userId" param.

from vertx-web.

Got it. Thanks for the clarification :)

from vertx-web.

That's a very interesting feature a lot of framework actually provide (RESTEasy, ...).

I think it could be called ParameterResolver.

The interface could look like this :

public interface ParameterResolver<T> {

    @Fluent
    public ParameterResolver<T> accept(T unboxed);

    @Fluent
    public ParameterResolver<T> reject(int statusCode, String reason);

    public String rawValue();

}

And then :

router.param("userId", resolver -> {
    Long userId;
    try {
        Long.parseLong(resolver.rawValue());
    } catch (Exception e) {
        resolver.reject(400, "Invalid user id");
    }
    mongo.find("users", new JsonObject().put("_id", userId), callback -> {
        if (callback.failed()) {
            resolver.reject(500, "Something is wrong with mongo");
        } else {
            List<JsonObject> matchingUsers = callback.result();
            if (matchingUsers.size() > 1) {
                resolver.accept(matchingUsers.get(0));
            } else {
                resolver.reject(404, "User not found");
            }
        }
    });
});

Then, resolver should be called first (before other handlers) for each route invokation, and contextHandlers should be called only once the parameter has been resolved.

Then, in RoutingContext, we could add a method like :

public void handle(RoutingContext context) {
    JsonObject user = (JsonObject)context.unboxedParam("userId");
    // ...
}

But I'm not sure if this generic approach (Resolver) works with the polyglot approach of Vert.x

What are your thoughts ?

from vertx-web.

The interface you described is not a functional interface so in Java8 you won't be able to use it as a lambda, if you have a simple functional interface:

@FunctionalInterface
public interface Handler {
    void resolve(RoutingContext context)
}

then you could inline it as:

router.param("userId", ctx -> {
    ... go to mongodb for example and in success
    ctx.next();
    ... or in error
    ctx.fail();
});

And this makes the Handler the same as a normal route handler so no need for extra types. BTW this is how it works with Yoke.

The behavior is that for each route registered with the router, all param names are extracted and these handlers are kept on a different list, then for each request the list of params in use is iterated and prefixed to the chain so it works like you're just iterating the normal middleware list.

If we would go with your interface we then cannot use the compact code of lambdas, it is just a matter of preference. I personally prefer less code.

from vertx-web.

I thought about ParameterResolver<T> as a way to abstract the RoutingContext.

So that maybe people could have their own implementations (not failing the RoutingContext directly, store something somewhere, notify some stuff).

Just in order to provide a simple way to accept / reject parameters.

And then yes, a functionnal interface that takes ParameterResolver<T> as parameter as you described. (with the resolve method) so that it's useable as a lambda. (didn't write the code for this one).

from vertx-web.

sidenote : the same mechanism, whether it involves ParameterResolver or context.put() directly could be used (with almost no additional effort) for query parameters.

router.route("/api/*").param("from", ctx -> { // or "resolver" instead of "ctx"
    String rawValue = ctx.request().getParam("from"); // or resolver.rawValue()
    try {
        Date fromDate = parseJSONDate(rawValue);
    } catch(ParseException pe) {
        ctx.fail(400); // or resolver.reject(400, "ISO 8601 Date expected");
        return;
    }
    ctx.put("fromDate", fromDate); // or resolver.accept(fromDate);
    ctx.next();
});

then in user's code :

Date d = ctx.get("fromDate"); // or ctx.unboxedParam("from")

Something like that.

from vertx-web.

The issue is clear however the style of the API does not match the current Vert.x-Web, since i reported it using Yoke's style.

I think it should be something like:

router.route("/api/*").param("from").handler(ctx -> {
    String rawValue = ctx.request().getParam("from");
    try {
        Date fromDate = parseJSONDate(rawValue);
    } catch(ParseException pe) {
        ctx.fail(400); // or resolver.reject(400, "ISO 8601 Date expected");
        return;
    }
    ctx.put("fromDate", fromDate); // or resolver.accept(fromDate);
    ctx.next();
});

Also the same for RegEx:

router.route("/api/*").param("from").handlerWithRegex("^(0|[1-9][0-9]*)$');

from vertx-web.

After giving more though and playing around with the API I am inclined to think this is method is not required in the API. The current implementation allows plugging multiple handlers on the same route, a param validator is just a simple handler, so we can get exactly the same result with it.

We can however implement a set of helper validators that validate if a param is Number, String, Date, etc, or matches a Regex and sets the value with the correct type in the context. e.g.:

router.route(/api/:apiKey").handler(ParamHandler.create("apiKey", "/^(?=[a-f\d]{24}$)(\d+[a-f]|[a-f]+\d)/"))

For complex scenarios, like we would do with the param we just use a normal handler:

router.route(/api/:apiKey")
  .handler(ctx -> {
    // go to the db fetch the value to the context
    // or fail
  })

In order to reuse it, all one would need is to declare the closure outside the handler method and give it a name:

Handler<RoutingContext> apiKeyValidator = ctx -> {
    // go to the db fetch the value to the context
    // or fail
  }

router.route(/api/:apiKey").handler(apiKeyValidator)
router.route(/api/:apiKey").handler(ctx -> {
  // at this moment apiKey is valid so do something...
})

from vertx-web.

I'm closing this issue for now since it would be adding duplicate functionality as described on the previous comment.

from vertx-web.