oxromantic

首先排除 3，否则 ps 你想从底边中间拉条直线到顶边中间，就永远拉不上去了

@2i2Re2PLMaDnghL pcf 是比较早的商业容器实现，大概被 vmware 收购了，具体没了解，既然你提到整个响应都会被替换，这就是我之前描述的场景，你以为的业务 response，实际已经被替换了，所以不能光靠 http status code 来处理业务，还需要加额外的逻辑，但既然加额外的逻辑，何必还抱死 http status code ；另外，我所谓的容器是广义的，譬如远古的 war 跑在 tomcat 里，那么 tomcat 就是 war 的容器，tomcat 自己也会用到 http status code 表达自己的状态

为什么？是什么让你产生这种误解？

ps: 你缺少的只是一些 ETag 、缓存声明之类，看看 2 种 response 的 header 差异吧

@2i2Re2PLMaDnghL pcf/k8s 都会啊，可以了解下

@2i2Re2PLMaDnghL 你搞错了，这些 status code 并不是你应用独占的，和容器抢这些 status code，就会给前端引入不确定性的混乱，而没有个前端定义一个可以直接判断属于业务数据的基础规则

@2i2Re2PLMaDnghL retrofit 你居然让换个正常点的框架？类似 ios 的 alamofire，都是 top1 的框架，都不建议在非 200 的 http status code 里处理业务逻辑

想想 http 的 code 有啥作用就能想通怎样用最好

举例来说，http 400 表示错误的请求，404 很多框架表示服务找不到不可达，这些都是属于预期之外的错误，在评估服务健康度的时候都需要采纳，如果混用，譬如把 404 作为常规业务逻辑（离谱点譬如搜索找不到就返回 404 ），就会产生很大的功能混淆，如果再集成一些网络日志框架（听 X 之类），简直就是业务和标准错误混合的灾难

可以参考下百度云 api 的设计，虽然百度云很流氓，但是不可否认 api 定义还是有参考价值的

另外我不同意上面说的持续测试只采用 http response code 来判断，这种属于没经历过 http 时代电信的鞭打以及没用过 cdn，永远不要相信 http response code 能代表你业务的状态，否则就是给项目埋雷

更新证书都折腾的设备，我的理解是没有 ssh，能说下还有啥使用价值吗