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
Right now, {id} can be used as a placeholder for variable parts of an URL. There are issues with the current approach:
The name inside the curly braces does not matter - it can't be referred to in the target URL.
The format is non-standard and quite inflexible.
I think that if we want to support URL rewriting we should adopt industry standards, which basically means using regular expressions. Using regular expressions is admittedly a bit more complicated than the current approach might be, but it is very efficient (expressions can be pre-compiled) and flexible.
The implementation should enable the following scenario:
Given the request URL `/books/123/chapters/456`,
and the rule `/books/([^/]+)/chapters(?<chapter_id>/?|/.*)` => `http://chapter-service:8080/v1/chapters/chapter_id`,
then the request is forwarded to `http://chapter-service:8080/v1/chapters/456`.
Right now,
{id}
can be used as a placeholder for variable parts of an URL. There are issues with the current approach:I think that if we want to support URL rewriting we should adopt industry standards, which basically means using regular expressions. Using regular expressions is admittedly a bit more complicated than the current approach might be, but it is very efficient (expressions can be pre-compiled) and flexible.
The implementation should enable the following scenario:
Proposed :re options:
:no_auto_capture
,:dupnames
,:unicode
,:anchored
,:caseless
.The text was updated successfully, but these errors were encountered: