希望额外增加一个按最新成交价的折扣排序

[Cliencer]

看了下爬虫源码，其中fetch_volume的过程中应该会收到形如以下的json返回，{"success":true,"lowest_price":"¥ 270.39","volume":"10","median_price":"¥ 212.02"}，其中"median_price"就是最近一小时内的成交中位数价，不知道大佬为何不把这个数据利用起来呢，非常需要一个按最新成交价的折扣排序~~~
————————————
另外Steam的历史价格的请求格式如下
price_history_fmt = r"https://steamcommunity.com/market/pricehistory/?appid={appid:d}&market_hash_name={hash_name:s}"
返回的是json格式，其中prices包含了过去每一小时的交易价格以及交易数量，可以按照这个计算出某个物品24小时内的平均成交价，一周内的平均成交价等等，如果可以的话（听说Steam API限制很严格）希望能够加入到数据库中方便查阅，谢谢大佬们的无私奉献~~~~

[Cliencer]

已提交PR

[EricZhu-42]

感谢贡献！我晚些来看一下。

其中"median_price"就是最近一小时内的成交中位数价

我们已经注意到 priceoverview 接口也返回了价格数据。但是，由于缺少可信的信息源以核实该价格数据的实际意义，我们一直没有将这部分数据纳入参考。此外，部分低成交量的饰品似乎不会返回该数据。如果有相关文档或讨论，欢迎随时补充。
（例如： 若 lowest_price 是 24 小时内的最低成交价格，median_price 是中位数价格，那为何有时 median_price 反而比 lowest_price 更低呢？）

另外Steam的历史价格的请求格式如下 ...

目前 Steam API 对请求频率限制极为严格。例如，从 itemordershistogram 接口获取实时求购/寄售单数量及价格需要高频更换代理 IP，其流量成本是目前 iflow.work 运行的最大支出项。通过历史价格计算出 24h/7d/30d 成交均价并展示的实现工程量不大，但带来的运行成本提升问题可能是无法忽视的。

总而言之，目前 iflow.work 提供的挂刀数据仅参考实时订单价格。对于某些成交量较低的饰品，通过实际成交价格计算挂刀比例的意义确实更大。如果 priceoverview 接口无法获得有意义的价格数据，通过解析 pricehistory 接口获取一定时间内的实际成交均价也是一种可行的方案。我们会积极考虑该提案，并在成本能够覆盖的情况下优先支持该功能。

[Cliencer]

感谢您的耐心回复。lowest_price并不是最低成交价，而是最低挂卖价，所以比median price高是很正常的，另外部分低成交量的饰品没有该数据可以通过对volume是否大于1来判断掉（您目前的源码就有这部分的判断），所以我认为在不增加额外的api请求情况下，增加这一部分的数据作为排序是比较方便的

[Cliencer]

出于成本考虑，如果不从官方api获取历史成交价格数据，可以考虑自行建立数据库，例如将每次获取的成交价格信息进行储存分析（实际上您目前关于这项api的请求仅利用了volume这个数据，其他的数据都被丢弃）

[EricZhu-42]

更正 #48 (comment) ：pricehistory 接口似乎验证登录 cookie，不带 cookie 时返回空结果 —— 那基本不太可能从这个接口拿数据了。

[EricZhu-42]

感谢您的耐心回复。lowest_price并不是最低成交价，而是最低挂卖价，所以比median price高是很正常的，另外部分低成交量的饰品没有该数据可以通过对volume是否大于1来判断掉（您目前的源码就有这部分的判断），所以我认为在不增加额外的api请求情况下，增加这一部分的数据作为排序是比较方便的

似乎没什么问题，晚些我合一下 PR，但前端还需要相应做一些小的调整，我尽量近期有空的时候改好部署到线上。感谢~

[Cliencer]

更正 #48 (comment) ：pricehistory 接口似乎验证登录 cookie，不带 cookie 时返回空结果 —— 那基本不太可能从这个接口拿数据了。

原来要带cookie吗，这个我确实没有注意到，感谢您的提醒，那确实不适合作为高频获取数据的选择，但自建数据库获得历史价格分析请您再考虑一下，如果可以的话我可以做这方面的数据整理工作，但这需要使用一部分的历史数据，在数据储存方面的结构需要一定程度的调整

[Cliencer]

感谢您的耐心回复。lowest_price并不是最低成交价，而是最低挂卖价，所以比median price高是很正常的，另外部分低成交量的饰品没有该数据可以通过对volume是否大于1来判断掉（您目前的源码就有这部分的判断），所以我认为在不增加额外的api请求情况下，增加这一部分的数据作为排序是比较方便的

似乎没什么问题，晚些我合一下 PR，但前端还需要相应做一些小的调整，我尽量近期有空的时候改好部署到线上。感谢~

提交的PR中我对综合的挂刀比率进行了修改（拍脑子凭感觉进行的加权），这方面需要您再调整一下

[EricZhu-42]

近期成交比例的显示及排序功能已在 iflow.work 上线。

我们计划重新设计 steam.iflow.work 的新 UI，并在功能完善后替换目前的默认 UI，届时将支持近期成交比例的显示功能。