构建用于批准或拒绝用户的 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 API 设计标准。我怀疑有什么，但你确实想知道一些anti-patterns被认为是“糟糕的 REST 设计”。
1）过度依赖querystring。
GET http://api.example.com/services?op=approve_request&userid=12345
这是一个典型的糟糕设计，因为 APIservices过于通用且缺乏描述性。
基本上，您只需使用 API 就可以做任何事情services。此外，HTTP 方法的使用也是不正确的，GET这表明 fetch/retrieve 应该保留用于其目的。对于更新应该是PUT并且创建应该是POST。
另一个缺点是可维护性，底层代码肯定会是一场噩梦，因为它的目的太通用了。
2) 错误的资源命名。
GET http://api.example.com/update_customer/12345
这个是名词和动词结合起来的update_customer。通常最好用API名词来命名 your。例如customer/account。
这更实用，因为DELETE通过关闭帐户PUT来修改帐户的详细信息，可以在请求的有效负载中描述修改详细信息。
GET另外，此处不应使用HTTP 方法。
一般来说，您不需要在 URL 中使用“更新”、“创建”或“删除”等动词，因为预期的操作可以从 HTTP 方法动词派生。
3）令人困惑的动词
PUT http://api.example.com/customers/12345/update
同样，动词不应包含在 中URL。这很令人困惑，因为你有PUThttp 方法，而且动词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。
| 归档时间： |
|
| 查看次数： |
4492 次 |
| 最近记录： |