激活软件 API 适合做成 RESTful API 吗？当序列号不存在时应该返回 200 然后在返回内容中加一个状态属性还是直接 404 状态码更好？

最近看了 RESTful API ，里面建议的是返回 404 状态码。感觉这个场合不太适合 RESTful API ，请问应该返回 200 然后 API 里再加一个状态属性还是直接 404 状态码更好？返回 404 的话感觉有一种 API 不存在的意思。

如果这个场合不适合 RESTful API ，那其它 RESTful API 应该和普通的 API 混在一起吗，还是 api/v1/ 下专门放 RESTful API ，其它 API 直接放 api/ 下？或者有什么更好的解决方案么？

qfdk

2022-03-07 15:04:07 +08:00

400 吧

dingwen07

2022-03-07 15:23:29 +08:00

200 ，并在返回内容中加状态属性

激活码的请求服务器可以处理，不算“malformed syntax”，因此 400 不适用。同样，服务器能够处理错误的激活码，404 也不适用。401 、403 自然也不适用。

Reference: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htm

fkdog

2022-03-07 15:26:42 +08:00

客户端提交了一个序列号，服务端可能会返回以下五种结果，
0. 激活成功
1. 提示序列号无效
2. 提示序列号已经达到设备激活上线
3. 提示序列号不适用于当前版本号
4. 提示序列号被锁定

如果你的客户端只是需要 echo 服务端返回的 message ，那么从 4xx 里调一个顺眼的即可。
但是假设现在有这么一个需求：
针对 1 ，echo 错误 message 。
针对 2 ，提示用户升级更高规格的产品服务，并打开升级页面。
针对 3 ，提示用户升级新版本序列号，并提供老客户升级优惠活动。
针对 4 ，提示用户进行解锁处理。

你发现单一一个 4xx 并不够用，实际上就算你用了 http status ，你依然需要一个 code 用来区分不同的返回结果，你总不能直接字符串去判断吧？

大公司其实也有 200 或者 400 的，没必要为了规范而规范，团队里约定好统一的处理方案即可。

harde

2022-03-07 15:33:05 +08:00

我们一般业务上的错误，Http 状态统一返回 422 ，具体错误代码、消息在返回的数据中。

Hanggi

2022-03-07 15:35:42 +08:00

你可以去看看 404 的定义，包括你所访问的资源不存在，也是 404 ，不仅仅是路径不存在。

libook

2022-03-07 15:45:02 +08:00

HTTP 状态码和业务状态码分别代表的是不同层级的状态，用 HTTP 状态码难以细分出各个业务状况，用业务状态码来代表 HTTP 状态会脱离 Web 标准化设计，所以建议两套都有，比如序列号不存在的时候，你可以认定为是客户端错误（表示 HTTP 协议层的错误信息），返回 HTTP 状态码 400 ，同时返回信息里有个业务状态代表序列号不存在。

不是所有 API 都适合用 REST 风格，你可以在路径规划上划分出哪些是 REST 、哪些不是，你可以在文档上标出哪些 API 是 RESTful 的，也可以通过类似于“/api/rest/v1”这种显眼的方式直接把 REST 和非 REST 隔离开，API 设计上最重要的是让对接双方的开发者都能看得懂，只要能达到这个目标就是好的设计。

REST 没有标准方案，只是一个 API 设计思路而已，所以你最终的设计只要符合 REST 的核心思想就可以享受 REST 带来的好处，不需要追求跟哪个具体案例一模一样。