v2 路由规范

[NeverBehave]

新的路由规范已经推送，文档：https://docs.rsshub.app/joinus/script-standard.html
我们同时更新了：

• 新路由后续将会自动发现并载入
• 增加路由并发限制，同一路由在首次获取未完成期间将会返回503，缓存到位后恢复：Cache 相关变更 #7740
• 添加了维护者列表
• 添加实验性json支持

如果在适配新版路由时遇到问题，请在下方留言

[NeverBehave]

第三方路由支持讨论正在收集中

[aidistan]

A reference from another website parsing extension: https://simpread.ksria.cn/sites/

[linbuxiao]

#8297

path: /third-party
method: POST
content-type: application/json
dep: koa-bodyparser 解析post请求体

目前想法是第三方路由的支持并不包含解析部分。只暴露一个接口，将抛来的对象转化为xml返回。

优点在于：

与目前的路由不冲突，作为功能性路由与其他路由同级存在。
分离parse步骤。页面格式复杂，使用get url ---> return xml的形式建立内容不太现实？
可使用云函数，git action等方式定时post解析后的对象给该接口，接收返回的xml。

还有一种没有pr的想法是：

采用分包的方法，将routes使用monorepo的方式进行管理。可以根据引入的包来加载需要的路由。自然也能很好的支持没有merge的路由。会对结构及其他有较大改动。但觉得这好像是不错的方法。

[aidistan]

建议提供一个案例解释说明方案，并补充相关说明文档，具体可参考 NeverBehave 在 #8224 中的做法

[linbuxiao]

建议提供一个案例解释说明方案，并补充相关说明文档，具体可参考 NeverBehave 在 #8224 中的做法

在pr中有给出，现在这里也补充了~

[aidistan]

建议解释说明得更充分一些，POST 从哪来？能否提供案例？安全问题怎么解决？

说明文档是指类似 docs/joinus/script-standard.md 这样的

[linbuxiao]

建议解释说明得更充分一些，POST 从哪来？能否提供案例？安全问题怎么解决？

说明文档是指类似 docs/joinus/script-standard.md 这样的

只是解析后返回了上下文对象，不存在执行，应该不会有安全问题？

这个方案只能是一个过渡方案：指在review - merge流程中的路由，可以通过用户自己配置的方式直接使用。真正解决的方案模式应该是像你所说的分离。

文档会尝试给出。非常感谢你的建议。

[linbuxiao]

#7891

很酷但有些重的实现？

[aidistan]

这个方案比较酷但其实没有解决 PR 中提到的问题。

关键还是需要核心开发者下定决心拆分为 core 和 routes 两个 repo，PR 才能真正分开处理：

• core 是 RSSHub 的核心，负责与其他组件交互，直接载入一方路由，以及载入 github repo、PR 等格式的三方路由
• routes 是官方维护的 route 推荐列表，通过 branch 或者锁定第三方 route repo commit 的方式固化路由插件版本
• 同时还需要提供一个 route-template 作为三方路由开发的起点

这样所有 routes 就分为了三个层级，可以让用户按需载入：

• built-in 内置级，官方维护的 mail/imap 等核心路由
• routes 推荐级
• 以及其他不在官方 routes 列表中，众多路由贡献者自行开发的

[linbuxiao]

这个方案比较酷但其实没有解决 PR 中提到的问题。

关键还是需要核心开发者下定决心拆分为 core 和 routes 两个 repo，PR 才能真正分开处理：

• core 是 RSSHub 的核心，负责与其他组件交互、直接载入一方路由、载入 github repo、PR 等格式的三方路由
• routes 是官方维护的 route 推荐列表，通过 branch 或者锁定第三方 route repo commit 的方式固化路由插件版本
• 同时还需要提供一个 route-template 作为三方路由开发的起点

这样所有 routes 就分为了三个层级，可以让用户按需载入：

• built-in 内置级，官方维护的 mail/imap 等核心路由
• routes 推荐级
• 以及其他不在官方 routes 列表中，众多路由贡献者自行开发的

非常清晰，其中分离的想法我很喜欢。和我上面提到的分包也有相通的地方。

采用分包的方法，将routes使用monorepo的方式进行管理。可以根据引入的包来加载需要的路由。自然也能很好的支持没有merge的路由。会对结构及其他有较大改动。但觉得这好像是不错的方法。

在这里存在一个讨论点在于：三方路由的实现形式应当是怎样的？repo，pr还是npm包？

[aidistan]

这个就看核心开发者的决断了~ 我个人偏好是 repo > npm > pr，执行起来做 repo（面向未来）和 pr（兼容现在）两个方案。

我翻了一遍 master 分支下的 routes，其实多数 route 还是比较简单的。可以考虑设计一个 .rsshub specification，然后实现单文件版的 route 加载，这个就很灵活了，从 URL 拉取或者 paste 都很方便。

[linbuxiao]

单文件是我没想过的方法！

[KimYangOfCat]

命名规范
我们会默认将所有的路由文件夹名字附加在真正的路由前面。路由维护者可以认定自己获取的就是根，我们会在附加对应的命名空间，在这空间底下，开发者有所有的控制权

关于命名规范这一点，是否可以考虑使用解析的 站点域名来作为文件夹的名字 ？利用目前域名的唯一性来减少未来文件夹域名冲突的潜在问题，同时也可避免开发者在同一站点的不同分类内容上重复造轮子。重复轮子可参考文档中的GNN1 与GNN2，根据我使用 google 搜索出来的结果，这俩应该是同一个站点的同一个内容，只是因为命名上的不同导致了重复开发！

最好是使用域名逆序命名方式，例如：kimyang.cn 这个站点的的文件夹命名应该是cn.kimyang，这样的命名方式在常见的操作系统的文件系统排序中会将相同的多级域名聚合在一起，有助于开发者快速发现哪些站点是已有的，减少发生重复开发的可能性。

[NeverBehave]

单站点多域名是可能的，我们保持使用自己的缩写，方便参照

[syrinka]

请问路由分包有进展了吗？

现在似乎已经快接近 2000 条路由了，各种意义上说都好重

[NeverBehave]

现在的v2路由，只需要删除/只保留对应的文件夹，已经算是某种程度上的分包了把。而且默认路由都是懒加载，启动的时间是很快的