使用MCLF-CN提供的公用API服务

Question

使用MCLF-CN提供的公用API服务

ZhaiSoul opened this issue a year ago · 58 comments

ZhaiSoul commented a year ago

检查项

我充分理解提交的建议可能无法所有启动器作者参与，并尊重所有启动器开发者的选择
我确认在Issues列表中并无其他人已经提出过与此问题相同或相似的问题
我确认该反馈并非针对单个启动器的，如果是，我将会去该启动器的反馈页面反馈

您是什么类型的用户

第三方网站管理/负责人（MC相关的）

请简单的说一下您的想法

考虑到国内部分地区使用第三方资源站可能出现访问比较困难的问题，现公开征求是否提供统一的第三方API接口，例如CurseForge、Modrinth和其他公用API。
将由组织统一采购使用腾讯云EdgeOne，并提供中心服务器。

现阶段暂时考虑实现的接口有：CurseForge、Modrinth接口的代理访问，启动器管理平台，统一公告通知平台。

鉴权：

CurseForge和Modrinth都拥有各自的appid等鉴权信息，为防止遇到冲突亦或者第三方API拉闸，每个启动器请求时将使用自己的第三方网站鉴权id。
初步的设想是由本平台提供一个启动器注册平台，然后可以自行在平台上填写自己的第三方接口的鉴权信息，最后请求本平台调用第三方API时，只需要header头带上启动器在本平台的标识，最终请求时将自动带上该启动器设置的鉴权appid。

缓存：

接口将根据需求开启CDN级缓存，同时也将开启离线缓存功能，将会在中心服务器维护/崩溃时，依然会读取之前缓存的API内容，降低中心服务挂掉带来的影响。

收费：

由于EdgeOne是根据请求数和CDN流量来进行收费，大部分成本将使用MCLF-CN的公共资金提供，但如果有特定启动器的用量确实过于高的话，将会以腾讯云公开的最低活动价的8折进行收费。
由于是纯API访问，实际上流量用得并不多，用的多的可能是请求数，参考价格如下：

如届时联系到云厂商提供赞助的话，我也会第一时间通知各位。

它能解决什么样的问题/带来什么样的帮助

能够利用国内网络加速用户访问部分非下载类型的海外服务，改善用户体验。
同时提供各大启动器的统一通知服务，所有启动器用户都能收到由MCLF-CN发布的通知。

期望的结果

统一使用第三方接口，减轻开发者的负担。

是否有对这个方案的相关链接？

No response

附注

No response

Answer 1 · 2024-02-01T06:51:00.000Z

还有公共资金的？

Answer 2 · 2024-02-01T08:22:32.000Z

thinking https://github.com/z0z0r4/mcim

~~在换备案，所以 CDN 掉了~~

Answer 3 · 2024-02-01T08:46:30.000Z

姑且，这里需要一些接口定义，返回值，或者决定要照抄源 API 的内容吗？

Answer 4 · 2024-02-01T08:50:01.000Z

CurseForge和Modrinth都拥有各自的appid等鉴权信息，为防止遇到冲突亦或者第三方API拉闸，每个启动器请求时将使用自己的第三方网站鉴权id。

既然 GET 请求会被缓存，全部 POST 请求用同一个也没啥问题吧，现在的请求大头就三个 x-api-key 对应三个启动器...至今为止也没见过被封的（？

Answer 5 · 2024-02-01T08:50:54.000Z

CurseForge和Modrinth都拥有各自的appid等鉴权信息，为防止遇到冲突亦或者第三方API拉闸，每个启动器请求时将使用自己的第三方网站鉴权id。

既然 GET 请求会被缓存，全部 POST 请求用同一个也没啥问题吧，现在的请求大头就三个 x-api-key 对应三个启动器...至今为止也没见过被封的（？

不止会带x-api-key，还可能带上启动器的UA等传给cf他们，方便他们统计

Answer 6 · 2024-02-01T09:09:13.000Z

这件事最起码的是启动器dev的支持以及资金来源吧...完全没有提及呢

Answer 7 · 2024-02-01T11:54:16.000Z

这件事最起码的是启动器dev的支持以及资金来源吧...完全没有提及呢

资金来源这个还在整理以及找老板中，暂时没新消息。主要先讨论这个提议有做下去的必要没

Answer 8 · 2024-02-02T08:35:21.000Z

目前 Modrinth 在国内访问状态良好，感觉没必要代理，倒是 CurseForge 问题非常大，如果有的话自然是最好的……

Answer 9 · 2024-02-02T13:29:02.000Z

哪些接口已经被启动器使用了呢？需要参考

在进行缓存的情况下，提供两个平台的全部信息工作量不小，是否应该提供聚合接口？

个人认为应该既然已经缓存了，就应该剔除多余信息，聚合接口仅留下以下需求所必须的信息

以下是我猜测的需求

搜索 Mod
单个/多个 Mod 基本信息，版本列表
具体版本信息
单个/多个 fingerprint，hash 检索

只是混合两个平台的数据还好

不清楚是否会使用这些数据，但 Mod 依赖、Mod 分类依据 需要详细定义，得根据两个平台定义...很麻烦

两个平台都有自己的分类依据，聚合显得有点困难，~~BakaXL 现有的是怎么做的？~~

Answer 10 · 2024-02-03T10:00:17.000Z

你可以在 PCL 的仓库里搜 api.curseforge.com 和 api.modrinth.com

Answer 11 · 2024-02-03T12:42:40.000Z

哪些接口已经被启动器使用了呢？需要参考

在进行缓存的情况下，提供两个平台的全部信息工作量不小，是否应该提供聚合接口？

个人认为应该既然已经缓存了，就应该剔除多余信息，聚合接口仅留下以下需求所必须的信息

以下是我猜测的需求

搜索 Mod

单个/多个 Mod 基本信息，版本列表

具体版本信息

单个/多个 fingerprint，hash 检索

只是混合两个平台的数据还好

不清楚是否会使用这些数据，但 Mod 依赖、Mod 分类依据 需要详细定义，得根据两个平台定义...很麻烦

两个平台都有自己的分类依据，聚合显得有点困难，~~BakaXL 现有的是怎么做的？~~

目前BakaXL是把两个接口的内容进行搜索后，以两个站点的内容合并交叉显示的。
然后只有部分字段聚合了一下，大部分字段我直接不让搜

Answer 12 · 2024-02-05T15:47:48.000Z

喔~ 这个好，有需要的话我可以做一个出来，爬虫我擅长啊 @bangbang93

Answer 13 · 2024-02-05T17:04:18.000Z

我这里再补充一点
服务器上面要统计哪些资源属于热门资源
热门资源是可以302到bmclapi的
需要请求通知到bmclapi
@bangbang93 你怎么看？

Answer 14 · 2024-02-06T01:51:44.000Z

我这里再补充一点服务器上面要统计哪些资源属于热门资源热门资源是可以302到bmclapi的需要请求通知到bmclapi @bangbang93 你怎么看？

这不提供 mod 下载吧...

我记得作者发钱按下载量算的，而且 bmclapi 这么高负载你还找它...

Answer 15 · 2024-02-11T06:28:38.000Z

还有七天开学，我是废物做不完了…这几天得出门，bad end

暂时搁置，大概是下个暑假才搞得完了

大佬们有兴趣的做吧，当然没人做带缓存的话我会继续找时间重构的

~~新的东西太多了不会调.jpg 步子大了拉到蛋又想陪特莉波卡当社会实践了~~

Answer 16 · 2024-02-11T06:31:19.000Z

可能的话，请保持 API 与原站完全一致
这样可以直接在启动器中修改 API Root，即可切换至镜像

Answer 17 · 2024-02-11T07:46:43.000Z

可能的话，请保持 API 与原站完全一致这样可以直接在启动器中修改 API Root，即可切换至镜像

这种不太好做到，毕竟某些参数不可能做到完全一致，如果和原站一样的话，那叫反向代理

Answer 18 · 2024-02-11T07:59:36.000Z

可能的话，请保持 API 与原站完全一致这样可以直接在启动器中修改 API Root，即可切换至镜像

这种不太好做到，毕竟某些参数不可能做到完全一致，如果和原站一样的话，那叫反向代理

能解释下那些参数不可能做到完全一致吗

Answer 19 · 2024-02-11T11:38:06.000Z

可能的话，请保持 API 与原站完全一致这样可以直接在启动器中修改 API Root，即可切换至镜像

这种不太好做到，毕竟某些参数不可能做到完全一致，如果和原站一样的话，那叫反向代理

能解释下那些参数不可能做到完全一致吗

姑且，全部一致在我这就是 model 写长点…留下必要的部分就行了，不少参数都是多余的或者不知道含义的…比如 isearlyaccess 这些

Answer 20 · 2024-02-11T13:47:57.000Z

这种不太好做到，毕竟某些参数不可能做到完全一致，如果和原站一样的话，那叫反向代理

抱歉，我用词不当。我希望我们的新 API 是原站的一个子集，即，API 路径不变、参数名称和类型不变（但可以少）

Answer 21 · 2024-04-04T07:00:51.000Z

支持国内有统一的minecraft resource index站点，但这个东西既需要钱也要大量技术，属实不好做的

Answer 22 · 2024-05-04T03:32:15.000Z

标准征求：

当未缓存，即数据库无记录，不确定是否真的不存在
- 拉取一份信息后返回源站结果（耗时可能较长）且容易触发阈值，目前是积累一定量后批量刷新缓存
- 返回异常状态码，客户端自行拉取
- - 直接报 404
- - 自定义状态码表示未缓存不确定
拉取的过期数据是否应该返回（返回的每份数据都有同步时间戳）

Answer 23 · 2024-05-04T03:33:38.000Z

建议直接定义 HTTP 状态码 600 Cache Not Found

Answer 24 · 2024-05-04T03:36:01.000Z

不要乱加定义，非304的响应都是算没有缓存

Answer 25 · 2024-05-04T03:36:52.000Z

定义非标准的状态码在无法控制全部客户端的情况下可能不是一个好主意

此场景使用404状态码似乎没有什么问题

Answer 26 · 2024-06-05T16:06:54.000Z

目前，HCML 与 PCL2 已经双双跑通，可以直接替换 url，~~前瞻体验~~

https://github.com/z0z0r4/mcim

仓库见 https://github.com/z0z0r4/PCL2 和 https://github.com/z0z0r4/HMCL

提供 build PCL2 和 HMCL

如遇到 404 等情况，等待几秒后再尝试就能拉取到数据了（首次缓存

~~目前缺少可靠性测试，如果有人愿意来写下 pytest 可太好了~~

~~当前搜索接口未缓存，直接拉取源，因此会较慢，即将改善~~

Answer 27 · 2024-06-05T16:26:06.000Z

umm 如果这能只提供 API 中转，但不能提供文件下载中转的话……连不上 CF 的玩家只是能看到文件列表了，但点进去也没法下载，似乎就意义不大……

Answer 28 · 2024-06-05T23:55:43.000Z

umm 如果这能只提供 API 中转，但不能提供文件下载中转的话……连不上 CF 的玩家只是能看到文件列表了，但点进去也没法下载，似乎就意义不大……

这个议题从一开始就没提供文件下载

以及听说 mod 开发者按下载量得报酬，这方面如何处理？

如果只是作为备线的话，我个人觉得可以考虑，不代表 @ZhaiSoul

PCL2 有收集关于每日 mod 文件下载量，以及针对无法下载文件这一缺口之类的指标可以作为参考吗？

缺少数据，没法评估成本

~~如果能够接受和 ob 当前一样的网盘策略，倒是可能~~

Answer 29 · 2024-06-06T07:52:37.000Z

我只是说考虑到实际的使用情况，就算用了 API 中转，问题也没有解决……对那部分无法访问的玩家而言，只是变成了能看文件列表，但还是不能下……

关于 CurseForge 的下载量统计，目前所有从 API 下载的文件似乎都不会计算下载量。
我个人的主观、片面的看法是，既然用的是 CurseForge 官方的 API，他们必然有能力把这部分下载计入。目前不计下载、不给 mod 作者报酬的情况，有可能是他们刻意而为之的，启动器作者没有任何办法解决。
但从结论上说，即使使用了文件中转，也不会影响下载量：因为 CurseForge 官方本来就不给计这个……

PCL 没有主动收集用户数据，我也不知道成本，但目测很高，不咋建议做……

Answer 30 · 2024-06-06T08:03:48.000Z

PCL 没有主动收集用户数据，我也不知道成本，但目测很高，不咋建议做……

没别的意思，统计数据我只是想参考下得挂几个节点

我只是说考虑到实际的使用情况，就算用了 API 中转，问题也没有解决……对那部分无法访问的玩家而言，只是变成了能看文件列表，但还是不能下……

这个，我正在照抄 bmclapi 挂载文件到网盘，估计会在端午前完成，可以期待

关于 CurseForge 的下载量统计，目前所有从 API 下载的文件似乎都不会计算下载量。我个人的主观、片面的看法是，既然用的是 CurseForge 官方的 API，他们必然有能力把这部分下载计入。目前不计下载、不给 mod 作者报酬的情况，有可能是他们刻意而为之的，启动器作者没有任何办法解决。但从结论上说，即使使用了文件中转，也不会影响下载量：因为 CurseForge 官方本来就不给计这个……

缓存了的话，curseforge 那边显示的下载量自然会少，没看懂 刻意而为之 啥意思...可能理解错了

我不太了解 mod 咋算报酬的，下载量是去年听说的，有没有懂行的大佬解释下？

Answer 31 · 2024-06-25T14:20:46.000Z

基本上，status 有了，可以看看稳定性

https://mcmod-info-mirror.github.io/status/

Answer 32 · 2024-06-25T14:23:21.000Z

umm 如果这能只提供 API 中转，但不能提供文件下载中转的话……连不上 CF 的玩家只是能看到文件列表了，但点进去也没法下载，似乎就意义不大……

关于文件 CDN 已经部署好了，测试后就可以启用=-=

和 bmclapi 一样是网盘缓存，未缓存的内容会重定向到源站

不包括整合包等大于 50M 的文件

已经缓存了全部的 modrinth mod ~~共 300G 左右~~

Answer 33 · 2024-07-16T07:11:19.000Z

缓存了的话，curseforge 那边显示的下载量自然会少，没看懂 刻意而为之 啥意思...可能理解错了

按照我的理解，使用 CurseForge 提供的 API 下载就绕过了官网的广告，这样 CurseForge 得到的收入就会减少，也就可以解释为什么是 刻意而为之

Answer 34 · 2024-07-16T14:13:05.000Z

缓存了的话，curseforge 那边显示的下载量自然会少，没看懂 刻意而为之 啥意思...可能理解错了

按照我的理解，使用 CurseForge 提供的 API 下载就绕过了官网的广告，这样 CurseForge 得到的收入就会减少，也就可以解释为什么是 刻意而为之

也就是说启动器下载一开始就无法为 Mod 作者提供报酬？

Answer 35 · 2024-07-16T19:33:50.000Z

是，这是 CF 那边干的，只要是通过 API 访问它都不计数，我们没有任何办法

Answer 36 · 2024-07-18T13:45:42.000Z

是，这是 CF 那边干的，只要是通过 API 访问它都不计数，我们没有任何办法

那我可就没任何心理负担了…镜像了也没影响人家收入…

Answer 37 · 2024-07-19T07:21:56.000Z

@burningtnt @LTCatt 征求下启动器的意见：如果接入的话，能否够接受额外的 CDN 鉴权，参考 https://cloud.tencent.com/document/product/228/76110

Answer 38 · 2024-07-19T07:28:30.000Z

@burningtnt @LTCatt 征求下启动器的意见：如果接入的话，能否够接受额外的 CDN 鉴权，参考 https://cloud.tencent.com/document/product/228/76110

没有意义。HMCL 全部开源，别人可以极其简单的伪造鉴权信息。

Answer 39 · 2024-07-19T08:19:39.000Z

没有意义。HMCL 全部开源，别人可以极其简单的伪造鉴权信息。

试试 GitHub 配置 Secret？

Answer 40 · 2024-07-19T08:24:54.000Z

没有意义。HMCL 全部开源，别人可以极其简单的伪造鉴权信息。

试试 GitHub 配置 Secret？

？？？HMCL 的代码毫无混淆。你以为 CURSE_API_KEY 这种是私有的吗？只要你敢把 HMCL 里的 META-INF/MANIFEST.MF 打开，API Key 全在里面

Answer 41 · 2024-07-19T09:51:06.000Z

@burningtnt @LTCatt 征求下启动器的意见：如果接入的话，能否够接受额外的 CDN 鉴权，参考 cloud.tencent.com/document/product/228/76110

没有意义。HMCL 全部开源，别人可以极其简单的伪造鉴权信息。

伪造鉴权是预料之内的，但可以简单的避免部分小鬼，考虑到你游的低年龄

虽说不适合类比，如果 PCL2 的远古版本下载不开鉴权肯定会更多人刷量

Answer 42 · 2024-07-19T09:57:45.000Z

你可以考虑加启动器 UA 过滤？

Answer 43 · 2024-07-19T09:59:20.000Z

UA 也能伪造。

Answer 44 · 2024-07-19T10:25:19.000Z

你可以考虑加启动器 UA 过滤？

我将来会加 UA 过滤

Answer 45 · 2024-07-19T10:26:02.000Z

咋样都能伪造的...没准备用它避免伪造，防点小鬼

主要鉴权得启动器写...所以征求下开发的意见...

Answer 46 · 2024-07-19T10:42:09.000Z

如果只是想避免从 log 复制网址的小鬼，那加 UA 检测其实就够了……

Answer 47 · 2024-07-19T11:50:58.000Z

复制网址下载的小鬼偶尔下一下应该不会造成过大负担吧，有刷量意图和能力的绕个UA也不在话下

Answer 48 · 2024-07-19T22:52:23.000Z

如果只是想避免从 log 复制网址的小鬼，那加 UA 检测其实就够了……

ok，那就这么办吧

Answer 49 · 2024-08-26T09:13:13.000Z

~~@ZhaiSoul 事实证明缓存命中率也就罢了50% 上下，只有一个默认 keyword 的 search 能吃 CDN 缓存，其他的都是不同 hash 的 post...离线缓存几乎毫无意义hhh~~

收回成见，请求流量还是能缓存到 50% 以上的...

Answer 50 · 2024-10-13T06:43:06.000Z

文件下载缺口巨大...急需有能力拉起文件下载的xd，实在无力

302 是回源的，301 是去 OpenMCIM 的

Answer 51 · 2024-10-13T07:48:20.000Z

能不能联系一下 OpenBMCLAPI 的支持方看看能不能也支持下 OpenMCIM？

Answer 52 · 2024-10-13T14:26:22.000Z

目前，HCML 与 PCL2 已经双双跑通，可以直接替换 url，~~前瞻体验~~
仓库见 https://github.com/z0z0r4/PCL2 和 https://github.com/z0z0r4/HMCL

我注意到 HMCL-dev/HMCL@main...mcmod-info-mirror:HMCL:main 这里你将 URL 中的 v1 和 v2 删去了。这样做是有什么特别的考虑吗？

除此之外，目前如果资源没有缓存，是返回 404 还是 302 回原站？

Answer 53 · 2024-10-13T14:38:44.000Z

目前，HCML 与 PCL2 已经双双跑通，可以直接替换 url，~~前瞻体验~~
仓库见 https://github.com/z0z0r4/PCL2 和 https://github.com/z0z0r4/HMCL

我注意到 HMCL-dev/HMCL@main...mcmod-info-mirror:HMCL:main 这里你将 URL 中的 v1 和 v2 删去了。这样做是有什么特别的考虑吗？

除此之外，目前如果资源没有缓存，是返回 404 还是 302 回原站？

Answer 54 · 2024-10-13T21:58:50.000Z

目前，HCML 与 PCL2 已经双双跑通，可以直接替换 url，~~前瞻体验~~
仓库见 https://github.com/z0z0r4/PCL2 和 https://github.com/z0z0r4/HMCL

我注意到 HMCL-dev/HMCL@main...mcmod-info-mirror:HMCL:main 这里你将 URL 中的 v1 和 v2 删去了。这样做是有什么特别的考虑吗？
除此之外，目前如果资源没有缓存，是返回 404 还是 302 回原站？

我发现我晚上有点搞混了未缓存文件是301会源 404是OpenMcim主控给出的状态码orz

Answer 55 · 2024-10-19T11:21:12.000Z

能不能联系一下 OpenBMCLAPI 的支持方看看能不能也支持下 OpenMCIM？

@bangbang93

~~但不太现实…文件数量和文件总大小都远远超过当前的 openbmclapi…~~

Answer 56 · 2024-10-19T11:28:09.000Z

目前，HCML 与 PCL2 已经双双跑通，可以直接替换 url，~~前瞻体验~~
仓库见 https://github.com/z0z0r4/PCL2 和 https://github.com/z0z0r4/HMCL

我注意到 HMCL-dev/HMCL@main...mcmod-info-mirror:HMCL:main 这里你将 URL 中的 v1 和 v2 删去了。这样做是有什么特别的考虑吗？

除此之外，目前如果资源没有缓存，是返回 404 还是 302 回原站？

该 pr 需要修改，失效了

如果 HMCL 有意愿我会提供相关支持

Answer 57 · 2024-10-19T11:38:05.000Z

目前，HCML 与 PCL2 已经双双跑通，可以直接替换 url，~~前瞻体验~~
仓库见 https://github.com/z0z0r4/PCL2 和 https://github.com/z0z0r4/HMCL

我注意到 HMCL-dev/HMCL@main...mcmod-info-mirror:HMCL:main 这里你将 URL 中的 v1 和 v2 删去了。这样做是有什么特别的考虑吗？
除此之外，目前如果资源没有缓存，是返回 404 还是 302 回原站？

该 pr 需要修改，失效了

如果 HMCL 有意愿我会提供相关支持

我还是很好奇你这个镜像的规则。我可以先把这类内容合并入 PR Collection

Answer 58 · 2024-10-19T12:16:44.000Z

目前，HCML 与 PCL2 已经双双跑通，可以直接替换 url，~~前瞻体验~~
仓库见 z0z0r4/PCL2 和 z0z0r4/HMCL

我注意到 HMCL-dev/HMCL@main...mcmod-info-mirror:HMCL:main 这里你将 URL 中的 v1 和 v2 删去了。这样做是有什么特别的考虑吗？
除此之外，目前如果资源没有缓存，是返回 404 还是 302 回原站？

该 pr 需要修改，失效了
如果 HMCL 有意愿我会提供相关支持

我还是很好奇你这个镜像的规则。我可以先把这类内容合并入 PR Collection

关于接口，姑且有文档，请问你稍微看过 README 了吗，值得怀疑...？https://mod.mcimirror.top/docs

关于未缓存的情况，请参考缓存策略

未缓存的 Mod 信息会根据请求的 API 类型进行处理，当前缓存率已经够高了 MCIM statistics

单个 Mod 相关请求会直接返回 404，因为无法确认到底是该 Mod 不存在还是未缓存入数据库
多个 Mod 的相关请求会返回已经缓存的数据，例如同时通过接口请求 A、B 和 C Mod 的信息，A 不在数据库而 B 和 C 存在，会返回 B 和 C 的内容，并标识为 trustable: False，全都不存在则仿照源站 API 的规则响应

除此之外，目前如果资源没有缓存，是返回 404 还是 302 回原站？

此处资源要分 API 信息还是文件，API 信息见上

如果指的是以下文件下载的接口，未被 MCIM 缓存的直接回源

/data/{project_id}/versions/{version_id}/{file_name}
/files/{fileid1}/{fileid2}/{file_name}