正确的HTTP状态代码可能缺席的实体:200或204或404
我已经搜索了很多关于此,并已发现不同的答案,而且,我的情况有点不同。正确的HTTP状态代码可能缺席的实体:200或204或404
上下文: 我有一个文件A,与可能的发送器S
服务器X(所以不是浏览器)请求从一个文件服务器上的Y上的发件人,但发件人不存在。
我应该服务器Ÿ回报:
- 200:与空对象(不是真的确定,危险的,在服务器X nullpointers)
- 204:一个正确的状态,我认为,但是这主要是用来当端点没有返回一般的数据时(例如发布,更新,删除),这可能会造成混淆
- 404:这绝对应该是.../sender/{sender_id}的答案。但在这种情况下,我们问文件的发件人,没有发件人是正确的答案...
那么,最好的做法是什么,或者是有另一种更适合这种做法。
在此先感谢!
广义规则:不要尝试使状态代码具体说明api或域模型的细节。这些消息是通用组件(如浏览器,缓存,代理)的消息,不需要知道任何关于域模型和集成协议的具体信息。
404:这绝对应该是.../sender/{sender_id}的答案。但在这种情况下,我们要求发件人的文件,没有发件人是正确的答案...
4xx类响应代码指示an error in the client request。换句话说,客户问这个问题是错误的。 404特别暗示客户处理了对错误集成资源的请求。
所以这不是你在找什么。
204:一个正确的状态,我认为,但是这主要是用来当端点不返回一般数据(例如后,更新,删除),这可能会造成混淆
204有非常具体的含义 - 是说在响应中提供的表示是零字节长。 “你让我把这个文件的内容发给你,我成功地这样做了,但顺便说一下这个文件是空的。”
所以如果缺席发件人的表示是零字节长,王牌!但是,如果该表示形式是空的json对象,那么
{}
然后204不在桌子上。
我建议404 Not Found
比赛最好的你的描述为“发件人不存在”
以防万一,在这里你可以看到的状态代码的列表:https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
这里有两种情况。
如果您要求集合例如:/ users并且服务器上没有可用的用户,那么您的服务应该返回200 OK并且列表为空。
如果您通过id请求资源例如:/ users/id,并且用户不可用,那么您应该返回404 NOT NOT,因为您正在搜索的用户ID在服务器上不可用。
根据你的情况(假设你正在请求一个资源集合),我可能建议返回200 OK与空列表。如果您无法控制服务器,则可能需要在客户端进行空检查。
我知道上述两种情况,并且我们在代码中的任何地方都实现了这种方式,但在这里它不是一个集合......正确的实现将是一个可选的
我会使用404,但它也取决于API的使用者如何使用您的API以及如何处理其他资源。一致性很重要。 –