我通常是RESTful API设计的粉丝,但我不确定如何将REST原则应用于验证API .
假设我们有一个用于查询和更新用户 Profiles 信息(名称,电子邮件,用户名,密码)的API . 我们认为公开的有用功能将是验证,例如查询给定的用户名是否有效且可用 .
在这种情况下有哪些资源?应使用哪些HTTP状态代码和/或标头?
首先,我有 GET /profile/validate
,它接受查询字符串参数并返回 204
或 400
如果有效或无效 . 但是 validate
显然是动词而不是名词 .
4 回答
您所描述的事物类型在其语义中肯定更具RPC样式,但这并不意味着您无法以RESTful方式实现目标 .
没有
VALIDATE
HTTP动词,那么你可以通过构建整个API获得多少 Value 呢?您的故事围绕为用户提供了确定给定用户名是否可用的能力 - 这对我来说就像一个简单的资源检索检查 -GET: /profile/username/...
- 如果结果是404,则名称可用 .这突出了客户端验证就是客户端 . 这是一个UI问题,以确保在发送到服务器之前在客户端上验证数据 . RESTful服务不会判断客户端是否已执行验证;它将根据其自己的验证逻辑简单地接受或拒绝请求 .
REST不是一个包罗万象的范例,它只描述了构建客户端 - 服务器通信的方式 .
您将REST与资源导向混淆,REST中没有任何内容表明您不能在URL中使用动词 . 在URL设计方面,我通常选择最具自我描述性的东西,天使是名词或动词 .
关于您的服务,我要做的是使用您用于更新的相同资源,但使用
test
querystring参数,因此当test=1
操作未完成时,您可以使用它来返回验证错误 .......和回应:
我们也遇到了同样的问题 . 我们让客户端推迟到服务器进行验证的原因是为了防止出现不匹配的规则 . 在对资源执行操作之前,服务器需要验证所有内容 . 对这些规则进行两次编码是没有意义的,并且它们有可能使它们不同步 . 因此,我们提出了一种似乎与REST一致的策略,同时允许我们要求服务器执行验证 .
我们的第一步是实现可以从元数据服务(
GET /metadata/user
)请求的元数据对象 . 然后,此元数据对象用于告知客户端如何进行基本的客户端验证(必需,类型,长度等) . 我们从数据库中生成大部分内容 .第二部分包括添加一个称为分析的新资源 . 例如,如果我们有服务:
我们将创建一个名为的新资源:
分析资源不仅包含发生的任何验证错误,还包含可能需要的相关统计信息 . 我们争论的问题之一是用于分析资源的动词 . 我们得出结论,它应该是一个POST,因为在请求时正在创建分析 . 然而,GET也有强烈的争论 .
我希望这对试图解决同一问题的其他人有所帮助 . 对此设计的任何反馈表示赞赏 .
在REST API中进行验证是很重要的 . 无论如何,您需要进行验证,并且不要在客户端使用它 . 在我的情况下,我只是在API中有一个约定,一个特殊的error_id表示验证错误,而在error_details中,每个feild都有一个错误消息数组,在这个PUT或POST调用中有错误 . 对于考生:
如果您对Web和移动应用程序使用相同的REST API,那么您只希望通过更新API来更改验证 . 特别是移动更新需要超过24小时才能在商店发布 .
这就是它在移动应用程序中的样子:
PUT或POST的响应用于显示每个字段的错误消息 . 这是来自使用React的Web应用程序的相同调用:
这样所有REST API响应代码如200,404他们的意思就像他们应该的那样 . 即使验证失败,PUT也会响应200 . 如果调用通过验证,响应将如下所示:
您可以做出可能的修改 . Maby在没有error_id的情况下使用它 . 如果tehre是error_details,只需循环它们,如果找到与字段同名的键,则将其值作为错误文本放入同一字段 .