ttv-rs

尝试统一 Rust 生态系统的 Twitch API。

为什么？

这个 crate 的集合是为了满足创建一个 “一个库统治所有！” 的愿望，以便使用 Rust 与 Twitch API 进行交互。最初我认为每个子 crate 都可能依赖于 crates.io 上的不同已存在的 crate，或者如果没有任何合适的 crate，则自行实现功能。然而，自从我开始这个项目以来，我意识到我最初认为只打算覆盖 Helix 和 TMI 的 twitch-api2 crate，实际上最终还打算覆盖其他大多数端点（见 这个 issue）。因此，这个库目前只提供了一种方式，可以将 twitchchat 和 twitch-api2 结合在一个依赖项中，并且具有更短的名称 😛

我还在考虑是否重新导出 twitch_api2 是实现以下目标的最佳方式，但这看起来很有希望。然而，即使那个 crate 最终覆盖了所有端点，我也可能会在上面尝试提供额外的便利功能，例如自动选择最佳端点的函数、利用 REST 或 pubsub 端点的聊天功能、Webhooks 服务器、UI、数据库集成等...

目标

• 覆盖 Twitch 文档中列出的所有 API 的全部内容
• 覆盖现在已知或未来发现的几个有用的 非官方端点
• 尽可能匹配 Twitch 文档的组织结构。
  • 这使得 crate 的用户更容易找到和交叉引用文档，并利用除 Rust 之外的技术教程，同时也使贡献者更容易添加文档。
• 灵活性
  • 只要合理，这个 crate 应该是实现无关的（例如，能够支持各种异步运行时、网络实现、序列化库等）
  • 用户应该能够避免编译他们不需要的功能。
    • 然而，在我看来，一个合理的默认功能集仍然 至关重要。目前所有 活动 和 已弃用 的 API 端点默认启用，但 非官方 端点则不是。

请注意，目前我对Museun的twitchchat crate印象非常深刻，如果所有其他模块都能模仿其API并且与之良好互操作，那就再好不过了。例如，您应该能够为所有端点使用相同的异步执行器。

同样，我是sans-io设计方法的粉丝，虽然如果库提供与其他库的可选集成来实际实现IO，对最终用户来说会更少一些样板代码，那也很好。

此外，正如我所述，我的想法深受Twitch4j设计的影响；然而，我不会完全遵循它。我也有一些自己的想法，关于如何组织这些事情。

进度

活跃的Twitch API

废弃的Twitch API

非官方Twitch API

贡献

目前我主要寻求对我和我的想法的反馈和输入，以及可能适合此项目的现有crate。PR欢迎，但请注意，我可能对如何组织和实现事情有很多看法，而且可能经常改变主意。

许可

根据MIT和Apache 2.0许可