关于response的约束问题

yjqiang commented 5 years ago

b站的response很多都是json的样子，里面有code等词条。但是b站的返回值混乱，有频繁、1024、未登录等信息。所以需要统一约束控制吧。不然返回的东西过于杂乱。

lzghzr commented 5 years ago

没太懂, 哪里需要这个吗?

yjqiang commented 5 years ago

没太懂, 哪里需要这个吗?

如果长时间运行，会看到“频繁，稍后重试”、“logout”、"code 1024"等等非正常的返回值。而又不可能对每种返回值的接受端都这么加一个if (code == 1024): ...，所以需要一个统一处理。对1024这些东西可以暴力重试一次。对logout提示就raise然后重登。

Vector000 commented 5 years ago

昨天发现破站的code好像又改了，现在raffle接口的访问被拒绝返回貌似变成了-403 现在觉得与其去揣摩变幻莫测的code，不如直接用msg 然后异常值直接throw new error

yjqiang commented 5 years ago

昨天发现破站的code好像又改了，现在raffle接口的访问被拒绝返回貌似变成了-403 现在觉得与其去揣摩变幻莫测的code，不如直接用msg 然后异常值直接throw new error

msg有英文有中文……你打算大家一起写个人工智能揣度么？

lzghzr commented 5 years ago

我留意一下

From: Vector000 notifications@github.com Sent: Friday, March 22, 2019 7:00:12 AM To: lzghzr/bilive_client Cc: lzzr; Comment Subject: Re: [lzghzr/bilive_client] 关于response的约束问题 (#127)

昨天发现破站的code好像又改了，现在raffle接口的访问被拒绝返回貌似变成了-403 现在觉得与其去揣摩变幻莫测的code，不如直接用msg 然后异常值直接throw new error

― You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/lzghzr/bilive_client/issues/127#issuecomment-475434547, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMxV0pXAEtAX13ugiomCx642lnzd8bMyks5vZA78gaJpZM4cAkUa.

yjqiang commented 5 years ago

没太懂, 哪里需要这个吗?

以及删除动态api这里，甚至-22之类的东西。很多时候基本不会出现，但是出现了，基本就程序异常。

indefined commented 5 years ago

如果你是指错误代码的意思的话，可以参考这个 https://github.com/fython/BilibiliAPIDocs/blob/master/README.md#通用错误代码但那个项目已经有点时间不更新了错误代码也不可能统计全，更多错误代码的意义只能是自己收到自己尝试判断。如果是指这个项目的业务逻辑的话，基本每个请求返回都会单独判断code==0，虽然错误回复种类五花八门但是正确的回应只有一种，所以哪怕收到乱七八糟的回应也会被忽略而不会异常，至于登录失效重新登录，这个项目是放在心跳里判断的，如果失效了到下一个心跳之前最多5分钟内无法抽奖问题也不大，但是这种操作确实是不太合理并且效率不高，原则上应该把涉及用户权限的请求抽象为user类的成员，一旦遇到登录失效可以立即刷新，但是这种抽象对于这个项目来说这种提升效果并不大，登录失效顶多也就一个月一次，遇到奇怪的回应概率并不高。顺便1024错误应该是不可重试的

yjqiang commented 5 years ago

如果你是指错误代码的意思的话，可以参考这个 https://github.com/fython/BilibiliAPIDocs/blob/master/README.md#通用错误代码但那个项目已经有点时间不更新了错误代码也不可能统计全，更多错误代码的意义只能是自己收到自己尝试判断。如果是指这个项目的业务逻辑的话，基本每个请求返回都会单独判断code==0，虽然错误回复种类五花八门但是正确的回应只有一种，所以哪怕收到乱七八糟的回应也会被忽略而不会异常，至于登录失效重新登录，这个项目是放在心跳里判断的，如果失效了到下一个心跳之前最多5分钟内无法抽奖问题也不大，但是这种操作确实是不太合理并且效率不高，原则上应该把涉及用户权限的请求抽象为user类的成员，一旦遇到登录失效可以立即刷新，但是这种抽象对于这个项目来说这种提升效果并不大，登录失效顶多也就一个月一次，遇到奇怪的回应概率并不高。顺便1024错误应该是不可重试的

其实你会发现code很多情况下没什么用，需要code+msg一起判定。

indefined commented 5 years ago

其实你会发现code很多情况下没什么用，需要code+msg一起判定。

错误的前提下是这样的，但是这个项目并不处理错误，并且多数错误也是无法处理的，这个项目判断的错误只有两种，登录失效放在心跳里，被封禁放在抽奖里，其它的只处理成功

yjqiang commented 5 years ago

其实你会发现code很多情况下没什么用，需要code+msg一起判定。

错误的前提下是这样的，但是这个项目并不处理错误，并且多数错误也是无法处理的，这个项目判断的错误只有两种，登录失效放在心跳里，被封禁放在抽奖里，其它的只判断成功

如果发生错误，比如返回给你抽奖频繁，稍后重试。或者万一在某个重要值给你返回一个-22之类的东西。怎么办？忽略？这也太稳了吧。

indefined commented 5 years ago

其实你会发现code很多情况下没什么用，需要code+msg一起判定。

错误的前提下是这样的，但是这个项目并不处理错误，并且多数错误也是无法处理的，这个项目判断的错误只有两种，登录失效放在心跳里，被封禁放在抽奖里，其它的只判断成功

如果发生错误，比如返回给你抽奖频繁，稍后重试。或者万一在某个重要值给你返回一个-22之类的东西。怎么办？忽略？这也太稳了吧。

目前是这样的，我个人也觉得除了LOG出来并没有什么处理的必要，反正概率也不高多数也是无法处理的。B站的前端有些地方处理得更加暴力，连LOG都懒得做，只要不是0通通显示请求错误

yjqiang commented 5 years ago

其实你会发现code很多情况下没什么用，需要code+msg一起判定。

错误的前提下是这样的，但是这个项目并不处理错误，并且多数错误也是无法处理的，这个项目判断的错误只有两种，登录失效放在心跳里，被封禁放在抽奖里，其它的只判断成功

如果发生错误，比如返回给你抽奖频繁，稍后重试。或者万一在某个重要值给你返回一个-22之类的东西。怎么办？忽略？这也太稳了吧。

目前是这样的，我个人也觉得除了LOG出来并没有什么处理的必要，反正也处理不了。B站的前端有些地方处理得更加暴力，连LOG都懒得做，只要不是0通通显示请求错误

所以我不满足于能用就行

indefined commented 5 years ago

其实你会发现code很多情况下没什么用，需要code+msg一起判定。

错误的前提下是这样的，但是这个项目并不处理错误，并且多数错误也是无法处理的，这个项目判断的错误只有两种，登录失效放在心跳里，被封禁放在抽奖里，其它的只判断成功

如果发生错误，比如返回给你抽奖频繁，稍后重试。或者万一在某个重要值给你返回一个-22之类的东西。怎么办？忽略？这也太稳了吧。

目前是这样的，我个人也觉得除了LOG出来并没有什么处理的必要，反正也处理不了。B站的前端有些地方处理得更加暴力，连LOG都懒得做，只要不是0通通显示请求错误

所以我不满足于能用就行

我也只是给你讲一下这个项目的业务逻辑而已，如果你是来建议这个项目功能的话，我也不是项目的作者，如果你是来请教怎么解决这个问题的话，前面我也给了一些能解答的东西虽然用处不大，也给你解释了目前项目并不处理这些问题大概也没什么可以给你解答的，作者也说了会给你留意一下，我就没什么可以帮忙的了

lzghzr commented 5 years ago

咦? 我倒是没想过这么多因为本项目大部分是使用的安卓app的api, 所以才长时间不更新依然能够使用至于B站给的乱七八糟的返回, 为了与app行为一致, 并没有单独处理的打算目前新版app正在朝webview发展, 所以本项目采用稍微低一些的版本, 直到版本被B站抛弃

yjqiang commented 5 years ago

咦? 我倒是没想过这么多因为本项目大部分是使用的安卓app的api, 所以才长时间不更新依然能够使用至于B站给的乱七八糟的返回, 为了与app行为一致, 并没有单独处理的打算目前新版app正在朝webview发展, 所以本项目采用稍微低一些的版本, 直到版本被B站抛弃

好吧，我自己的项目由于有有需要长久挂机的人，所以很关心这方面，之前只是屏蔽了1024，但是现在看来还有很多未知json格式，初步打算是单独写一个格式限定（每个api配置一个）。

yjqiang commented 5 years ago

咦? 我倒是没想过这么多因为本项目大部分是使用的安卓app的api, 所以才长时间不更新依然能够使用至于B站给的乱七八糟的返回, 为了与app行为一致, 并没有单独处理的打算目前新版app正在朝webview发展, 所以本项目采用稍微低一些的版本, 直到版本被B站抛弃

个人更倾向于web端，所以经常有未知的东西，我之前只是简单收集了一些code。因为有长久挂机的，所以目前为了进一步提高稳定性，需要把api的约束写好，这样返回的数据不用一堆if else了，只需要判定自己需要的几种格式即可，而且可以预防未知的错误格式。

yjqiang commented 5 years ago

我自己已经写出了基本的模块，初步感觉不错，预期会大大减少波动，当然这需要不断地收集信息。 https://github.com/yjqiang/bilibili-live-tools/issues/103 https://github.com/yjqiang/bili2.0/commit/c1e0c205b2c68ace2f25c1f23ba75d52f3f0035e

yjqiang commented 5 years ago

https://github.com/santinic/pampy.js js 的模糊匹配可以用这个

ShmilyChen commented 4 years ago

现在app里面好像包含code列表

bilive / bilive_client

关于response的约束问题 #127