意外的路径变量类型：400与404之间的区别

Question

假设我们有以下 API：

GET /api/colors/{color}
GET /api/integers/{number}

在代码中，我希望'color'将匹配枚举中的某个值，并且'number'为整数。

例如：

GET /api/colors/red
GET /api/integers/2

会响应HTTP 200状态码。

但是对于这样的请求，我该如何响应：

GET /api/colors/foo
GET /api/integers/bar

如果颜色“foo”和整数“bar”不存在，应该返回404吗？还是因为客户端未使用一些约定的允许值（枚举，整数）而返回400？

- Valdemaras

Answer 1

一个返回 404 的资源在以后可能会变成 200。

例如，你查询的颜色今天不可用，但明天可能会添加：

GET /api/colors/lightblue

应该响应404。

而像/api/integers/bar这样的请求是格式错误的，将来也会是格式错误的，因此应该用400进行响应；整数从语义上来说永远不能是字符串。

发送400告诉客户端“不要再查询这个了”，客户端可以隐式地“记住”（缓存）这个答案。 404告诉客户端“现在我没有你请求的内容，请稍后再试”。客户端可以根据启发式或明确指示进行缓存。

- Daniel W.

---

/api/integers/bar 在我的应用程序中可能被视为格式不正确，但根据标准它是完全有效的。不同的API对于什么是格式不正确的URI有不同的理解，这样做是否可以接受？ - Valdemaras

@Valdemaras 或许“malformed”这个词不太准确。它是一个有效的URI，但涉及到你的API语义时，它是无效的。并没有标准，只有最佳实践。像你这样的问题很多都会被关闭，因为答案是一种观点，而不是标准。 - Daniel W.

我猜你说得对，这只是个看法问题。只是一开始不清楚它没有任何标准 :( - Valdemaras

Answer 2

“color 'foo'”和“integer 'bar'”不存在，所以应该返回404吗？ 404。

所有4xx状态码都会告知客户端请求存在问题。语义上的区别在于，404暗示目标URI存在拼写错误。

我们关注的原因之一是：404是可缓存的；通用组件可以记住请求的响应，并在重复请求时节省与服务器的往返时间。

- VoiceOfUnreason