ttv-rs

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

为什么？

这个 crate 集合的诞生源于创建一个 "一个库统治它们全部！"的 的愿望，以便使用 Rust 与 Twitch API 进行交互。最初我以为每个子 crate 很可能都依赖于 crates.io 上的不同现有 crate，或者如果没有合适的，则自己实现功能。然而，自从我开始这个项目以来，我意识到 twitch-api2 crate，最初我以为它只打算涵盖 Helix 和 TMI，实际上最终也打算涵盖大多数其他端点（见 此问题。因此，这个库目前只提供了一种方式，可以将 twitchchat 和 twitch-api2 结合在一个依赖项中，并且名称更短 😛

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

目标

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

请注意，目前我对Museun的twitchchatcrate印象非常深刻，如果所有其他模块都能模仿其API并且与之良好交互，我将非常高兴。例如，您应该能够为所有端点使用相同的异步执行器。

同样，我是sans-io库设计方法的粉丝，尽管如果库能提供与实现IO相关的其他库的选项性集成也很不错，这样用户就不需要编写太多样板代码。

此外，正如我之前提到的，我的想法深受Twitch4j设计的影响；然而，我并不会完全遵循它。我对如何组织事物也有一些自己的看法。

进展

活动的Twitch API

已弃用的Twitch API

非官方Twitch API

贡献

目前我主要寻求对我的愿景和想法以及可能适合此项目的现有crate的反馈和意见。欢迎PR，但请注意，我对如何组织实现有很强的观点，并且可能会经常改变想法。

许可证

根据MIT和Apache 2.0许可