25 | 路由与终结点:如何规划好你的Web API
自定义约束实现了路由约束接口,它只有一个 Match 方法,这个方法传入了 Http 当前的 httpContext,route,routeKey
这个 routeKey 就是我们要验证的 key 值
后面两个参数 RouteValueDictionary 就是当前可以获取到的这个 routeKey 对应的传入的值是什么值,这样就可以验证我们传入的信息
routeDirection 这个枚举的作用是当前验证是用来验证 URL 请求进来,验证是否路由匹配,还是用来生成 URL,是进还是出的这样一个定义,在不同的场景下面可能响应的逻辑是不一样的
下面的逻辑是如果路由是进来的,也就是通过 URL 配置 action 的情况,就做一个判断,根据 routeKey 取到当前输入的这个值,然后判断它是否可以转成 long,这个其实模拟了类型验证,比如说 long 型验证的方式
namespace RoutingDemo.Constraints
{
public class MyRouteConstraint : IRouteConstraint
{
public bool Match(HttpContext httpContext, IRouter route, string routeKey, RouteValueDictionary values, RouteDirection routeDirection)
{
if (RouteDirection.IncomingRequest == routeDirection)
{
var v = values[routeKey];
if (long.TryParse(v.ToString(), out var value))
{
return true;
}
}
return false;
}
}
}
RouteDirection
namespace Microsoft.AspNetCore.Routing
{
public enum RouteDirection
{
IncomingRequest = 0,
UrlGeneration = 1
}
}
接下来看一下约束是如何注入到我们系统里生效的
可以给我们的约束起一个名字 isLong,这个名字就是用来 Attribute 上面标识约束的
services.AddRouting(options =>
{
//options.ConstraintMap.Add("MyRouteConstraint", typeof(MyRouteConstraint));
options.ConstraintMap.Add("isLong", typeof(MyRouteConstraint));
});
OrderController 里面也修改为 isLong
/// <summary>
///
/// </summary>
/// <param name="id">必须可以转为long</param>
/// <returns></returns>
//[HttpGet("{id:MyRouteConstraint}")]// 这里使用了自定义的约束
[HttpGet("{id:isLong}")]
//public bool OrderExist(object id)
public bool OrderExist([FromRoute] string id)
{
return true;
}
启动程序,输入34,返回响应码200,输入abc,返回响应码404,也就是自定义约束生效了
接下来讲一下链接生成的过程
/// <summary>
///
/// </summary>
/// <param name="id">最大20</param>
/// <param name="linkGenerator"></param>
/// <returns></returns>
[HttpGet("{id:max(20)}")]// 这里使用了 Max 的约束
//public bool Max(long id)
public bool Max([FromRoute]long id, [FromServices]LinkGenerator linkGenerator)
{
// 这两行就是分别获取完整 Uri 和 path 的代码
// 它还有不同的重载,可以根据需要传入不同的路由的值
var path = linkGenerator.GetPathByAction(HttpContext,
action: "Reque",
controller: "Order",
values: new { name = "abc" });// 因为下面对 name 有一个必填的约束,所以这里需要传值
var uri = linkGenerator.GetUriByAction(HttpContext,
action: "Reque",
controller: "Order",
values: new { name = "abc" });
return true;
}
/// <summary>
///
/// </summary>
/// <param name="ss">必填</param>
/// <returns></returns>
[HttpGet("{name:required}")]// 必填约束
public bool Reque(string name)
{
return true;
}
启动程序,端点调试,输入1,点击执行,可以看到
path 的值为
/api/Order/Reque/abc
uri 的值为
https://localhost:5001/api/Order/Reque/abc
在定义 Controller 的时候,实际上还会做一些接口废弃的过程,通过 [Obsolete]
/// <summary>
///
/// </summary>
/// <param name="ss">必填</param>
/// <returns></returns>
[HttpGet("{name:required}")]// 必填约束
[Obsolete]
public bool Reque(string name)
{
return true;
}
我们不必直接删除我们的接口,它还可以正常工作,但是我们可以把它标记为已废弃,在 Swagger 上面会有体现
可以看到这个接口已经被标记为废弃的,但是它的调用还是可以工作的
总结一下
1、Restful 不是必须的,只要约束好 Http 方法以及 URL 地址,还有 Http 响应码,响应的 Json 格式,这些约定只要适合团队的协作习惯就可以了,也就是说需要定义好 API 的表达契约
2、建议是把 API 都约束在特定的目录下面,与其他功能性页面进行隔离,比如说 /api /api 加版本号这样子的方式
3、在废弃 API 的过程中间,应该是间隔版本的方式废弃,也就是说先将即将废弃的 API 标记为已废弃,但是它还是可以工作,间隔几个版本之后将代码删除掉
到目前为止,讲解了依赖注入,配置日志,中间件等必要的内容,下一节开始将进入微服务实战的部分
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
欢迎转载、使用、重新发布,但务必保留文章署名 郑子铭 (包含链接: http://www.cnblogs.com/MingsonZheng/ ),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。
如有任何疑问,请与我联系 (MingsonZheng@outlook.com) 。