主要观点:在设计 Dropshot 时避免了过去框架的一些问题,多数框架可为每个路由指定处理链,虽可指定在每个请求前后运行的处理程序,但多年使用后发现难以跟踪特定请求的控制流和理解处理链中不同处理程序间的隐式依赖,导致开发 API 服务器耗时且易出错。Dropshot 尝试不同做法,若处理程序主要目的是在处理程序间共享代码,可依靠现有机制即函数调用。风险是易遗漏重要函数调用,如用户认证或授权。目前在复杂实现中尚未遇到此需求,计划创建返回类型化值的实用函数模式,如在 Node.js 中可添加早期认证处理程序填充request.auth
,在 Dropshot 中则有返回AuthzContext
结构体的认证函数,需要认证的东西以函数参数形式消费AuthzContext
,此方式可组合,如有授权函数返回AuthnContext
,返回AuthnContext
的实用函数可消费AuthzContext
,需要授权的东西只需消费AuthnContext
且知道已认证和授权(可能在该结构中有细节),目前尚早,可能需要框架中更丰富的功能,但希望此方法能使开发复杂 API 服务器更快速和顺畅,若使用 Dropshot 可反馈使用情况。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。