我使用的是葡萄树,我想路由具有查询字符串的请求流量,而且我对正则表达式不太了解,也不知道为什么它不能工作。
(例如)
http://localhost:1234/service/function?param1=1¶m2=2我的RESTRoute是这样定义的:
[RESTRoute(Method = HttpMethod.GET, PathInfo = @"^/service/function\?\D+$")]
public void HandleFooRequestString(HttpListenerContext context)
{
PrintRequest(context);
this.SendTextResponse(context, "foo is a success!");
}但是发送给URL的流量不会被发送到该方法。我做错了什么?
发布于 2015-11-09 22:26:06
这是一个相当常见的问题,并产生了一些变化的葡萄路线图。
葡萄3.1.0 +
在最新版本的Grapevine中,查询字符串在正则表达式模式匹配之前从URL中删除,因此这不再是一个问题。
此外,在版本4中正在更新路由以匹配节点/快速路由机制,因此如果您愿意,可以选择根本不使用正则表达式。然而,这个版本仍处于规划阶段。
葡萄3.0.x
虽然GET请求包含查询字符串参数并不少见,但我们首先要确保我们使用的是正确的URI设计。若要引用奥赖利氏,第233页,在header URI设计(强调)下:
在设计URI时,使用路径变量来分离层次结构的元素,或者通过有向图分离路径。示例:
/weblogs/myweblog/entries/100从一般到特定。从一个weblog列表,到一个特定的weblog,到那个weblog中的条目,再到一个特定的条目。从某种意义上说,每个路径变量都“在”前一个路径变量中。 使用标点符号将同一层次结构中的多个数据块分开。在项目的顺序重要时使用逗号,就像在纬度和经度:/Earth/37.0,-95.2中所做的那样。当顺序不重要时使用分号:/color-blends/red;blue。 只使用查询变量来建议插入到算法中的参数,或者当其他两种技术失败时。如果两个URI仅在它们的查询变量中不同,这就意味着它们是同一底层算法的不同输入集。
这里最大的优点是,一般来说,我们的URI应该只使用查询字符串将参数传递给算法。实际上,如果我们在方法中期望查询字符串参数,这些参数应该通过请求路由到的方法进行验证,并且我们的PathInfo正则表达式应该反映接收此类参数的可能性。
示例:当不使用查询字符串时
假设您想要请求用户数据,给出一个特定的数字用户id,比如说632。在这种情况下,使用查询字符串可能很有诱惑力,但最好不要使用。
/user?id=632/user/632然后,更正确的URI的RESTRoute将如下所示:
[RESTRoute(Method = HttpMethod.GET, PathInfo = @"^/user/\d+$")]
public void GetUser(HttpListenerContext context)
{
var userid = context.RawUrl.GrabFirst(@"^/user/(\d+)$");
// you got your user id, do something
}示例:正确使用查询字符串
如果您想要创建一个将两个整数相乘的REST路由,那么-留出URI应该表示资源,而不是资源上的操作--使用查询字符串可能更合适。
/2/product/3/product?x=2&y=3然后,可能更正确的URI的RESTRoute将如下所示:
[RESTRoute(Method = HttpMethod.GET, PathInfo = @"^/product")]
public void MultiplyTwoIntegers(HttpListenerContext context)
{
var x = context.Request.QueryString["x"];
var y = context.Request.QueryString["y"];
// Verify the inputs and do the math.
}注意,PathInfo正则表达式省略了尾随的$,这通常表示字符串的结束,我们让路由方法处理参数的传递。如果我们真的想成为一个粘人的人,我们也可以这样写:
[RESTRoute(Method = HttpMethod.GET, PathInfo = @"^/product\?.+$")]这至少可以确保查询字符串中可能有一些参数,但这并不是真正必要的,因为我们无论如何都要进行检查。
https://stackoverflow.com/questions/33619469
复制相似问题