Comments (10)
@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.
Related Issues (20)
- `WebClient.close()` does not return a `Future` or wait for resources to be released HOT 4
- Possibility to close connection HOT 3
- Can't handle http2 errors in StaticHandler AsyncFile HOT 1
- oauth2 should not redirect (HTTP 302) XHR requests HOT 2
- HttpContext.fail() does not release the connection when invoked in SEND_REQUEST phase
- WebClient: NPE on misformatted Date or Expires header HOT 1
- absoluteURI is null when host header is missing HOT 2
- Issue with POST request hanging indefinitely in Vert.x Web HOT 3
- CSRF validation fails because CSRFHandler updates the session AFTER the session is already flushed HOT 1
- SockJS Event Bus Bridge does not keep web sessions alive for clustered session managers
- When upgrade vertx4, the path cannot support colon, and vertx 3 is ok HOT 1
- Use the new `OAuth2AuthorizationURL` in `OAuth2AuthHandler.extraParams`
- Reduce heavy atomic operations on RoutingContextImplBase HOT 1
- Rx Version of OAuth2AuthHandler Handler fails to add scopes HOT 2
- Vertx web randomly returns 404 error for certain POST requests even though for other similar requests it returns 200 HOT 2
- ChainAuthHandlerImpl#postAuthentication throws NPE HOT 1
- BodyHandler should not be added before the ProxyHandler HOT 2
- after RoutingContext.reroute(), TimeoutHandler still occured HOT 1
- Request to add localstorage-functonalities HOT 1
- GraphQL: Combination of request batching and Automatic Persisted Queries fails HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vertx-web.