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

400 吧

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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