V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
rv54ntjwfm3ug8
V2EX  ›  程序员

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

  •  
  •   rv54ntjwfm3ug8 · 2022-03-07 14:46:35 +08:00 · 2408 次点击
    这是一个创建于 752 天前的主题,其中的信息可能已经有所发展或是发生改变。
    最近看了 RESTful API ,里面建议的是返回 404 状态码。感觉这个场合不太适合 RESTful API ,请问应该返回 200 然后 API 里再加一个状态属性还是直接 404 状态码更好?返回 404 的话感觉有一种 API 不存在的意思。

    如果这个场合不适合 RESTful API ,那其它 RESTful API 应该和普通的 API 混在一起吗,还是 api/v1/ 下专门放 RESTful API ,其它 API 直接放 api/ 下?或者有什么更好的解决方案么?
    14 条回复    2022-03-11 00:32:41 +08:00
    qfdk
        1
    qfdk  
       2022-03-07 15:04:07 +08:00 via iPhone
    400 吧
    dingwen07
        2
    dingwen07  
       2022-03-07 15:23:29 +08:00 via Android
    200 ,并在返回内容中加状态属性

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

    Reference: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htm
    fkdog
        3
    fkdog  
       2022-03-07 15:26:42 +08:00   ❤️ 1
    客户端提交了一个序列号,服务端可能会返回以下五种结果,
    0. 激活成功
    1. 提示序列号无效
    2. 提示序列号已经达到设备激活上线
    3. 提示序列号不适用于当前版本号
    4. 提示序列号被锁定

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

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

    大公司其实也有 200 或者 400 的,没必要为了规范而规范,团队里约定好统一的处理方案即可。
    harde
        4
    harde  
       2022-03-07 15:33:05 +08:00
    我们一般业务上的错误,Http 状态统一返回 422 ,具体错误代码、消息在返回的数据中。
    Hanggi
        5
    Hanggi  
       2022-03-07 15:35:42 +08:00 via iPhone
    你可以去看看 404 的定义,包括你所访问的资源不存在,也是 404 ,不仅仅是路径不存在。
    libook
        6
    libook  
       2022-03-07 15:45:02 +08:00   ❤️ 1
    HTTP 状态码和业务状态码分别代表的是不同层级的状态,用 HTTP 状态码难以细分出各个业务状况,用业务状态码来代表 HTTP 状态会脱离 Web 标准化设计,所以建议两套都有,比如序列号不存在的时候,你可以认定为是客户端错误(表示 HTTP 协议层的错误信息),返回 HTTP 状态码 400 ,同时返回信息里有个业务状态代表序列号不存在。

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

    REST 没有标准方案,只是一个 API 设计思路而已,所以你最终的设计只要符合 REST 的核心思想就可以享受 REST 带来的好处,不需要追求跟哪个具体案例一模一样。
    keller
        7
    keller  
       2022-03-07 20:41:09 +08:00
    这种重要的验证场景还是不要用状态码来表示激活状态,很容易被劫持伪造验证状态。
    数据至少要双向加密
    PolarBears
        8
    PolarBears  
       2022-03-07 21:55:53 +08:00
    我认为应该直接全返回 200 ,返回内容是加密后的字符串,需要在客户端解密才能读取数据再做进一步处理。
    axisray
        9
    axisray  
       2022-03-07 23:46:53 +08:00 via iPhone
    强烈建议后端能处理的异常用 200 ,别用什么 400/500 ,现在网络环境复杂,说不定就被什么防火墙给替换页面了(血泪教训)
    axisray
        10
    axisray  
       2022-03-07 23:50:19 +08:00 via iPhone
    特别有些公司运维、安全、开发是分离的,测的时候好好的,上线就挂逼,然后互相扯皮。
    AyaseEri
        11
    AyaseEri  
       2022-03-08 09:53:42 +08:00
    建议只要请求打到你的服务器了,你能正确 handle ,一律 200
    yolee599
        12
    yolee599  
       2022-03-08 15:41:16 +08:00
    服务器能收到的请求一律返回 http 状态码为 200 ,再在 body 里单独定义一个业务状态码。
    zhilincom
        13
    zhilincom  
       2022-03-08 23:09:05 +08:00
    @axisray #9 现在都上 HTTPS 了还会被劫持?
    axisray
        14
    axisray  
       2022-03-11 00:32:41 +08:00 via iPhone
    @zhilincom 看情况,有时候是在负载上统一做 https 的,内部还是 http
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   958 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 21:45 · PVG 05:45 · LAX 14:45 · JFK 17:45
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.