标准化“第三方游戏资源索引”的实现和调用方式

[Silverteal]

此提案对现有情况主要的改变在于上述“可选”部分，如果要引入更多同层级的源，元数据对于识别等用途是必不可少的。不过考虑到在可以预见的未来，应该不会有其它镜像源/索引出现，对于这些改动的要求其实并不紧迫，所以目前列为可选项。

---

检查项

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

您是什么类型的用户

普通用户

请简单的说一下您的想法

基本参照BMCLAPI的现有API，标准化第三方游戏资源索引的实现，并将索引和实际下载源一定程度上解耦。

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

允许高级用户自定义BMCLAPI/MCBBS/官方以外的其它资源索引，以及为将来现有API的端点（URL前缀，下同）变化作准备

期望的结果

期望中，标准化的索引实现应该：

1. 维护资源/版本（forge/fabric/optifine/本体等）列表，对列表中的每个资源/版本提供索引。
2. 在客户端请求某一资源/版本时将客户端重定向到可用的实际下载源，或直接返回相关文件。如果选择前者，则这个下载源可能是官方的、索引提供方维护的镜像源、或者其它第三方镜像源。实际下载源的实现不包含在索引规范中，可以自行实现签名等安全性措施。
3. （可选）提供某个元数据接口，可能包含第三方索引的名称，描述和图标，以及3中提到的公告接口。
4. （可选）提供某个状态和公告接口，参考#1，向客户端/启动器推送机器可读的下载源、索引可用性信息和人类可读的，下载源和索引的维护情报、服务降级等信息，方便客户端排除自身网络问题。这个接口地址应该由元数据接口提供，地址应该固定（使用静态托管？）以便启动器及时获取下载服务的可用性情况。

期望中，标准化实现第三方索引的启动器应该：

1. 可以通过不同的索引端点访问版本列表/资源/版本文件，并正确处理重定向。出于安全考虑，也可以只提供预设。
2. 能够正确请求并解析元数据（如有）并展示。
3. 能够正确识别并处理索引服务和下载服务状态（如有），并展示服务公告（如有）。

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

No response

附注

基本部分就是照着BMCLAPI描的，并加入了一些可选部分

[burningtnt]

基本以 BMCLAPI 为标准吧

[Pigeon0v0]

其他资源索引按照 BMCLAPI 标准实现的话工作量不是很大吧（

[zkitefly]

按照第三方镜像可以按照 BMCLAPI 的标准，然后只需修改 apiRoot 即可达成效果

[bangbang93]

BMCLAPI压力最大的不是索引，是文件，索引才几个字节。 整那么多索引而且又和实际存储分离的话，索引的时效性如何保证？

[Silverteal]

BMCLAPI压力最大的不是索引，是文件，索引才几个字节。 整那么多索引而且又和实际存储分离的话，索引的时效性如何保证？

索引只是一个概念，用来解释“请求文件后被302到实际地址”这个现象（同时也是302状态码的本义），同时提供一种“分离”的可能性和名义（更好的例子我还没有想出来，先假设比如说：包含某些远古版本的“索引”没有能力提供文件分发服务，从而将请求“索引”到betacraft源，对常规版本则“索引”到官方源），使用“索引”一词受到了一些PyPI的影响，如果对理解有碍，也可以改变。

由于实际文件地址仍然通过索引下发，所以所有的文件仍然可以由索引提供者（镜像源）维护，BMCLAPI不需要作出破坏性改变。

对于启动器方面，目的在于使镜像源成为必要时可替换的，像MCBBS源引入时所做的那样。也正因为很多启动器已经实现了MCBBS源和BMCLAPI源的混合，启动器应该也不需要作很多底层的改动。

此提案对现有情况主要的改变在于上述“可选”部分，如果要引入更多同层级的源，元数据对于识别等用途是必不可少的。不过考虑到在可以预见的未来，应该不会有其它镜像源/索引出现，对于这些改动的要求其实并不紧迫，所以目前列为可选项。

[burningtnt]

修改 API Root 就好了

本质上，302 的规则也是一种“索引”，而 302 的 Location 则是文件

[Silverteal]

鉴于本稿件在理解上的歧义，现将其暂时归档。待后续完善或时机成熟后再次提出。