我正在开发一个REST服务,我正在努力遵守Roy Fielding博士的惯例和指导方针.
我将我的服务描述为暴露一组资源的端点.资源由URI标识,并且api客户端可以通过使用HTTP语义来操纵资源(即,不同的HTTP谓词映射到URI上的相应操作).
指南声明这些URI应以分层方式定义,反映对象层次结构.这在资源创建中很有用,因为在后端我们需要数据来执行创建操作.然而,在进一步的操作中,URI中包含的许多信息甚至不会被服务使用,因为通常仅资源Id足以唯一地标识操作目标.
一个例子:考虑一个暴露产品创建和管理的Api.还要考虑产品与品牌相关联.在创建时,执行以下操作是有意义的:HTTP POST/Brand/{brand_id}/Product [包含创建产品所需的输入的正文]
创建返回使用位置标头创建的HTTP 201,该位置标头公开新创建的产品的位置.
在进一步操作时,客户可以通过以下方式访问产品:HTTP PUT/Brand/{brand_id}/Product/{product_id} HTTP DELETE/Brand/{brand_id}/Product/{product_id}等
但是,由于产品ID在产品范围内是通用的,因此可以执行以下操作:/ Product/{product_id}我只保留/ Brand/{brand_id}前缀以用于一致性原因.事实上,该服务忽略了品牌ID.你认为这是一个好的做法,并且为了保持一个明确,明确的ServiceInterface定义是合理的吗？这样做有什么好处,这是一种方法吗？
此外,任何有关URI定义最佳实践的指针都将受到赞赏.
提前致谢
我正在使用ServiceStack实现Api.我的解决方案的一个关键方面是积极的验证策略.
我使用ServiceStack的ValidationFeature,这意味着如果在应用程序容器中注册了IValidator <ReqDto>(或其后代:AbstractValidator <ReqDto>),则验证将在服务之前自动运行.
通过积极验证,我的意思是我检查所有可能的错误情况,以及验证器级别的逻辑验证.因此,我的服务逻辑非常简洁.
从实际的角度来看,服务验证的服务逻辑的这种独立性是非常好的,因为它提供了非常容易阅读和推理服务逻辑/实现的原因.但是,我开始认为FluentValidation的规则和规则集更适合简单的格式验证,而不是直接在我正在进行的数据库访问(主要是测试源自请求中提取的ID的404错误).
问题:
1:验证逻辑在概念上访问数据库是否不正确？
2:从我所看到的,到目前为止,包括SS源,我没有找到一个形式来定义的情况下,如FluentValidation规则:从请求拉一个ID,访问数据库中检索一个实体,并抛出一个404如果没有找到进入.我只使用FV规则来定义基本格式验证,例如:
RuleFor(x => x.UserName).NotEmpty();
RuleFor(x => x.Password).NotEmpty();
其余的我手动做.有解决这个问题的人吗？
注意:这不是关于如何将ValidationResult/ValidationError转换为HttpResult/HttpError的问题.通过使用SS 3.9.44中引入的ValidationFeature的ErrorResponseFilter,我已经介绍过了.谢谢