You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should reserve some characters to support path parameters in the future.
I propose to reserve $ as a trigger for path parameters.
Examples:
/users/$id:int/page: this parses the ID parameter as int
/users/bar:foo: this does nothing because the path parameter doesn't start with a $
/users/$id/page: invalid, missing type information.
If this syntax is okay we can just forbid path segments to start with $ for now and revisit this feature in a future version.
If we do this inside the framework implementation would be quite simple and we can ensure a strict and well defined type checking. To access those path parameters we could just put them as a secure form inside the incoming request object.
The text was updated successfully, but these errors were encountered:
I'd rather not do that before we have a design for path parameters handling. Most importantly, I'm not sure this should belong to the core framework, or to an interceptor.
We should reserve some characters to support path parameters in the future.
I propose to reserve
$
as a trigger for path parameters.Examples:
/users/$id:int/page
: this parses the ID parameter asint
/users/bar:foo
: this does nothing because the path parameter doesn't start with a $/users/$id/page
: invalid, missing type information.If this syntax is okay we can just forbid path segments to start with
$
for now and revisit this feature in a future version.If we do this inside the framework implementation would be quite simple and we can ensure a strict and well defined type checking. To access those path parameters we could just put them as a secure form inside the incoming request object.
The text was updated successfully, but these errors were encountered: