rag*_*lka 6 rest http http-status-codes mongodb
我想找到适当的状态代码返回,这是我到目前为止的想法:
GET /api/documents/1 - 文件存在,用户有权访问 - 200 OKGET /api/documents/2 - 文档存在,用户无权访问 - 403禁止访问GET /api/documents/3 - 文件不存在(无法检查是否有访问权限) - 404 Not Found?403禁止?GET /api/documents/a - id无效(应该是一个数字) - 400 Bad Request?404找不到?403禁止?我的后端(使用MongoDB)目前的问题是,我做的第一件事是检查用户是否可以通过检查文档ID来查看他有权访问的文档ID列表.如果在列表中找不到document_id,则会自动返回403 Forbidden.这有助于我避免首先从数据库中获取文档以查看用户是否可以访问它.
我不确定这里最好的做法是什么 - 我应该追求更好的HTTP状态代码(从而创建额外的数据库请求),还是最后2个案例(3和4)的403 Forbidden工作?
she*_*ley 11
我会为#3和#4 建议404.
1. GET/api/documents/1 - 文档存在,用户有权访问 - 200 OK
200是合适的.
2. GET/api/documents/2 - 文档存在,用户无权访问 - 403禁止访问
403是合适的.
3. GET/api/documents/3 - 文件不存在(无法检查是否有访问权限) - 404 Not Found?403禁止?
这里 404是合适的,因为文档不存在于指定的URI中.
4. GET/api/documents/a - id无效(应该是一个数字) - 400 Bad Request?404找不到?403禁止?
这里仍然适合 404,因为指定的URI上不存在资源.作为参考, 400指的是格式错误的语法,但URI和请求在语法上完全有效; 只是您的服务器上没有相应的资源可用.
通常,您应首先考虑API并遵循标准HTTP方法.这是否需要另一个内部数据库请求是一个实现细节.我建议避免过早优化,特别是那些会对客户产生直接影响的优化.
我想说的是,对于场景 #3,使用 HTTP 代码,使用 404(因为找不到资源,但如果找到的话,用户将具有访问权限),对于场景 #4,使用 400(因为这确实是一个错误的请求) )。
这可以帮助您的实施客户了解到底出了什么问题。特别是对于 404,它在许多系统中都会在正常操作中出现(即查询登录凭据或类似的东西),客户端可能需要了解其请求未得到满足的确切原因。
我不明白返回正确的状态代码将如何导致更多的数据库请求。对于合法的 403 用例,您仍然可以返回 403。
| 归档时间: |
|
| 查看次数: |
5357 次 |
| 最近记录: |