[译]使用DOT语言和GraphvizOnline来可视化你的ASP.NETCore3.0终结点01 (2)

A ValuesController endpoint routing application

在这个图中还有很多事情要做,因为我们现在有了可变的路由参数值(路由模板中的{id},在图中显示为{...})和HTTP动词约束(GET/PUT/POST等等)

当我第一次看到这个图表时,我很难理解它。每个节点都是终结点吗?当然不是,如/api/不应该产生响应。那这个呢?至于HTTP: *端点呢,它们会产生响应吗?

为了进一步了解,我查阅了可以生成这些图的ASP.NET Core中的代码,但它有点复杂,不幸的是,由于大量使用internal类。我将在稍后的文章中探讨这些代码。

为了更好地理解端点图,我们需要了解并非所有的节点都是相同的。在下一节中,我们将深入研究这个简单图中的不同类型的节点,然后研究一个更好的图形表示(至少在我看来!)

了解不同类型的节点。

图中的每个节点都与给定的“深度”相关联。这是应该已经匹配的URL段数。例如,/api/Values/节点的深度为2-它要求空段/和/api段已经匹配。

当请求到达EndpointRoutingMiddleware(由UseRouting()添加)时,将传入的请求URL与此图进行比较。试图从树梢的根节点开始,通过图表找到一条路径。URL段与图中的边进行增量匹配,并在图中遍历一条路径,直到整个请求URL匹配为止。

每个节点(由在ASP.NET Core中的DfaNode中)有几个属性。我们目前感兴趣的属性是:

Matches*这是与该节点相关联的Endpoint(S)。如果通过路由匹配此节点,则这是将被选择用于执行的Endpoint。

Literals这些是连接节点的边缘。如果DfaNode有Literals,它具有可以进一步遍历以到达其他节点的文字段。例如,/api/节点包含一个有/Values值的Literal,则指向/api/Values节点。

PolicyEdges这些边缘是基于URL以外的约束进行匹配的。例如,图中基于动词的边,如HTTP: GET,是策略的边缘,指的是不同的DfaNode.

Parameters如果节点具有支持路由参数的边缘(例如,{id}), Parameters指向处理匹配参数的节点。这在图中是用/*边表示的。.

还有一个附加的属性,CatchAll,这在某些图形中是相关的,但我现在将忽略它,因为我们的API图并不需要它。

基于这些特性,我们可以通过使用DOT语言的其他特性,如形状、颜色、线型和箭头:

A ValuesController endpoint routing application with different styling

上图中添加了以下内容:

没有任何关联的节点Endpoint都以默认样式显示,即黑色气泡。

有Matches的显示为填充的棕色盒子。这些节点具有Endpoint,这可以产生响应。对于上面的API示例,这适用于已选择谓词的节点以及健康检查端点。

文字段边缘显示为默认的黑色边缘,带有一个填充箭头。

Parameters边缘(/*)以蓝色显示,使用菱形箭头。

PolicyEdges以红色显示,带有虚线和空三角形箭头。

现在,我承认我的设计技巧很烂,但是我认为您可以同意这个图表显示的信息比默认的要多!

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zwzxgw.html