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

[rv54ntjwfm3ug8]

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

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

[qfdk]

400 吧

[dingwen07]

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

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

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

[fkdog]

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

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

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

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

[harde]

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

[Hanggi]

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

[libook]

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

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

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

[keller]

这种重要的验证场景还是不要用状态码来表示激活状态，很容易被劫持伪造验证状态。
数据至少要双向加密

[PolarBears]

我认为应该直接全返回 200 ，返回内容是加密后的字符串，需要在客户端解密才能读取数据再做进一步处理。

[axisray]

强烈建议后端能处理的异常用 200 ，别用什么 400/500 ，现在网络环境复杂，说不定就被什么防火墙给替换页面了（血泪教训）

[axisray]

特别有些公司运维、安全、开发是分离的，测的时候好好的，上线就挂逼，然后互相扯皮。

[AyaseEri]

建议只要请求打到你的服务器了，你能正确 handle ，一律 200

[yolee599]

服务器能收到的请求一律返回 http 状态码为 200 ，再在 body 里单独定义一个业务状态码。

[zhilincom]

@axisray #9 现在都上 HTTPS 了还会被劫持？

[axisray]

@zhilincom 看情况，有时候是在负载上统一做 https 的，内部还是 http