REST API 批准/拒绝用户

Question

构建用于批准或拒绝用户的 RESTful 资源的正确方法是什么？

此资源旨在由管理员审查用户。管理员可以批准或拒绝用户请求。请求需要有 user_id和 updated_status那可能是 approved或 rejected .

我拥有的两个选项是:

1)将其分类为两个api:

PUT api/users/:user_id/approve/
PUT api/users/:user_id/reject/

或者

2)

PUT api/users/:user_id/review/
   -status passed through request body

任何意见或建议将不胜感激。

Answer 1

我不记得是否有任何人们通常遵循的具体 REST API 设计标准。我怀疑有没有，但你确实想知道一些 anti-patterns这被认为是“糟糕的 REST 设计”。

1)过度依赖querystring .

GET http://api.example.com/services?op=approve_request&userid=12345

这是一个经典的糟糕设计，因为 API services过于笼统和非描述性。

您基本上可以只使用 API services 做任何事情.另外HTTP方法的使用也是错误的， GET描述 fetch/retrieve 的内容应该保留用于其目的。更新应该是 PUT并创建应该是 POST .

另一个缺点是可维护性，底层代码肯定会成为一场噩梦，因为它太通用了。

2) 错误的资源命名。

GET http://api.example.com/update_customer/12345

这个有名词和动词的组合 update_customer .通常最好命名您的 API在名词中。例如。 customer/account .

这比做 DELETE 更实用可以意味着关闭帐户， PUT修改帐户的详细信息，其中修改详细信息可以在请求的有效负载中描述。

此外，HTTP 方法 GET不应该在这里使用。

通常，您不需要在 URL 中使用诸如“更新”、“创建”或“删除”之类的动词，因为预期的操作可以从 HTTP 方法动词派生。

3)混淆动词 PUT http://api.example.com/customers/12345/update
同样，动词不应该包含在 URL 中。 .这很令人困惑，因为您有 PUT http 方法和动词 update也在那里。

建议的解决方案

对于你的情况。您有 user和 request作为资源。
我认为 API 可以设计为；

批准请求 :
PUT http://api.example.com/user/12345/request
创建新请求 :
POST http://api.example.com/user/12345/request
拒绝请求 :
DELETE http://api.example.com/user/12345/request
不是删除实际请求，而是将状态更新为 Reject .