检查用户名是否有效的API端点的最佳名称

时间:2018-01-05 09:49:52

标签: rest api naming-conventions restful-architecture

我将设计一个RESTful API,用调用者提供的用户名检查是否有任何错误(例如重复,无效字符或黑名单中列出的名称......)。 / p>

API应该将检查结果(有效或无效)返回给调用者,以便调用者知道他是否可以使用此用户名。

如何命名API端点?

我原本以为GET /checkUserName/{username}GET /isUserNameValid/{username}是我的API的好名字。但我不确定他们是否真的很好。而且我不知道如何方便他人接受我提出的名字。

GET是http方法。 username是调用者提供的参数。

我已阅读以下两篇文章:

10 best practices for better restful api

RESTful API Designing guidelines — The best practices

但似乎我的API名称不符合上述文章中描述的所有指南。

其中一条指南说

  

使用名词但没有动词

遵循此指南,GET /checkUserName/{username}不合适。因为它包含动词check

GET /isUserNameValid/{username}也不合适。因为is是一个动词。

那么,如果我必须遵循RESTful设计的指导原则,那么API的最佳名称是什么?

我无法想到一个不包含动词的合适名称。

3 个答案:

答案 0 :(得分:6)

听起来您正在尝试构建RPC API,但又想将其称为REST。 :)

一点点background information on the differences

通常我会尝试建议重构,因为通常最好在服务器端处理验证,定义JSON Schema并与前端共享,这样他们也可以在本地使用JSON Schema验证器并匹配验证。

"重复"条件是JSON Schema无法验证的一件事,我确信用例是其中一个用户名框,可以在提交实际表单之前立即反馈用户名的好坏。

所以有一些方法。

1。)微服务

Buzzword是的,但是经常需要做一个特定事情的小小端点,特别是如果那个东西有点RPC而API的其余部分是REST API,我使用一个小服务

通常,用于RAD的API是用PHP或Ruby编写的,并且有一些巨大的框架,但是对于一些需要快速工作的小系统我经常使用像Go这样的小东西。

你当然可以使用相同的语言,通常的Sinatra vs Rails差异发挥作用。这可能只是一个RPC

2.)REST Crowbar

所以为了使它成为RESTful,你只想创建一个新的资源类型,它需要是这样的:

POST /username-checks

{ "username": "foo" }

我不太喜欢这样,但可能是因为我们还没有考虑过更好的设计。

3。)老大哥

只要注册表格中输入了一封电子邮件,就可以保存到目前为止填写的所有内容。

可以是POST /users,其中包含已填充的字段,默认状态为" potential",或者可能是其他POST /user-potential资源。这取决于你,但很早就发布很少的想法有两个好处。

  1. 你可以向人们做废弃的购物车式提醒,以便完成他们的帐户"这在电子商务领域变得越来越普遍
  2. 创建此资源后,您有一个可以PATCH反对的UUID。
  3. 尝试使用无效的用户名修补PATCH会给您带来验证错误。

    PATCH /users/<uuid>
    
    { username: "admin" }
    

    对于您的错误,请考虑使用RFC 7807: API Problems,这太棒了。

    我不想在这里设置错误的三分法,可能还有其他一些方法,但我真的考虑1或3,其中2可能是我扔了为了给出完整的答案。

答案 1 :(得分:1)

我其实更喜欢这个

POST /usernames/:username/check

因为它将username转换为资源,为将来处理用户名的API端点铺平了道路,例如

POST /usernames/:username/exists

答案 2 :(得分:0)

我打算做的是通过处理我想根据某些规则与它们所属的对象分开验证的字段,通过在它所属的对象下面创建该字段的子资源,然后尝试为它创建(POST)一个值。如果它返回 409,则已经存在一个。如果它返回 200 OK 或 201 Created 那么它是有效的。 400 表示验证失败。

或者,我正在考虑对该字段的特定实例(用户输入的数据)执行 GET,如果它返回 404,则它是唯一的并且不存在。如果您需要进行某种其他业务规则验证而不是唯一性,我认为这不会奏效。