构建用于批准或拒绝用户的 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
任何意见或建议将不胜感激。
【问题讨论】：
标签： rest
我不记得是否有任何人们通常遵循的具体 REST API 设计标准。我怀疑有什么，但你确实想知道一些被认为是“糟糕的 REST 设计”的anti-patterns。
1) 过度依赖querystring。
GET http://api.example.com/services?op=approve_request&userid=12345
这是一个典型的糟糕设计，因为 API services 过于通用且缺乏描述性。
您基本上可以只使用 API services 做任何事情。此外，HTTP 方法的使用也不正确，描述 fetch/retrieve 的GET 应保留用于其目的。更新应该是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。
【讨论】：
api 并不是一个坏习惯。我见过已建立的系统和开源项目，其 UI 类似于 http://www.ToanTran.com，然后服务器端将是 http://www.ToanTran.com/api/user/12345/request。
DELETE 方法关闭客户帐户的设计，例如DELETE http://xxx/customer/account 为了可追溯性，系统并没有真正从数据库中删除帐户。它只是将帐户记录标记为过期。
PUT 拒绝请求。相同的 URL PUT http://api.example.com/user/12345/request，然后在 HTTP 请求的正文中，可能有一个 JSON 对象来表示类似“{ status = Reject }”的内容。我认为这可能不像原始解决方案那样干净。同样，这里没有对错。
要使这更加 RESTful，您有 2 个真正的选择：
approved 或status 属性，只有管理员可以修改。api/users/:user_id/approval-status 之类的资源，而不是api/users/:user_id/approve 和api/users/:user_id/reject。此资源应包含告诉客户用户是否已获得批准的实际信息，并且管理员可以更改此信息。根据经验，如果您的 url 中有动词，那么您很可能在做一些不是 RESTful 的事情。你的动词是approve、reject和review，肯定都是错的。
【讨论】：
status 的属性。单一资源很好。我更喜欢@Samuel 的回答。我们可以按方法类型对 approve 和 reject 进行分类:)