如何以RESTful方式公开验证API？

Question

我通常是RESTful API设计的粉丝,但我不确定如何将REST原则应用于验证API.

假设我们有一个用于查询和更新用户个人资料信息(名称,电子邮件,用户名,密码)的API.我们认为公开的有用功能将是验证,例如查询给定用户名是否有效且可用.

在这种情况下有哪些资源？应使用哪些HTTP状态代码和/或标头？

首先,我有GET /profile/validate一个查询字符串参数并返回204或400有效或无效.但validate显然是动词,而不是名词.

Answer 1

您所描述的事物类型在其语义中肯定更具RPC样式,但这并不意味着您无法以RESTful方式实现目标.

没有VALIDATEHTTP动词,那么你可以从围绕它构建整个API获得多少价值？您的故事围绕为用户提供确定给定用户名是否可用的能力 - 这听起来像是简单的资源检索检查 GET: /profile/username/...- 如果结果是404,则名称可用.

这突出了客户端验证就是客户端.这是一个UI问题,以确保在发送到服务器之前在客户端上验证数据.RESTful服务不会判断客户端是否已执行验证; 它将根据其自己的验证逻辑简单地接受或拒绝请求.

REST不是一个包罗万象的范例,它只描述了构建客户端 - 服务器通信的方式.

Answer 2

我们也遇到了同样的问题.我们让客户端推迟到服务器进行验证的原因是为了防止出现不匹配的规则.在对资源执行操作之前,服务器需要验证所有内容.对这些规则进行两次编码是没有意义的,并且它们有可能使它们不同步.因此,我们提出了一种似乎与REST一致的策略,同时允许我们要求服务器执行验证.

我们的第一步是实现可以从元数据服务(GET /metadata/user)请求的元数据对象.然后,此元数据对象用于告知客户端如何进行基本的客户端验证(必需,类型,长度等).我们从数据库中生成大部分内容.

第二部分包括添加一个称为分析的新资源.例如,如果我们有服务:

GET /users/100

我们将创建一个名为的新资源:

POST /users/100/analysis

分析资源不仅包含发生的任何验证错误,还包含可能需要的相关统计信息.我们争论的问题之一是用于分析资源的动词.我们得出结论,它应该是一个POST,因为在请求时正在创建分析.然而,GET也有强烈的争论.

我希望这对试图解决同一问题的其他人有所帮助.对此设计的任何反馈表示赞赏.

Answer 3

您将REST与资源导向混淆,REST中没有任何内容表明您不能在URL中使用动词.在URL设计方面,我通常选择最具自我描述性的东西,天使是名词或动词.

关于您的服务,我要做的是使用您用于更新的相同资源,但使用testquerystring参数,因此当test=1操作未完成时,您可以使用它来返回验证错误.

PATCH /profile?test=1
Content-Type: application/x-www-form-urlencoded

dob=foo

......和回应:

HTTP/1.1 400 Bad Request
Content-Type: text/html

<ul class="errors">
  <li data-name="dob">foo is not a valid date.</li>
</ul>