ttv-rs

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

为什么？

这个crate集合的诞生源于创建一个"一个库统治所有!"来使用Rust与Twitch API交互的愿望。最初我以为每个子crate都可能依赖于crates.io上不同的已存在的crate，或者在找不到合适的crate时自己实现这些功能。然而，自从我开始这个项目以来，我意识到我最初认为仅打算涵盖Helix和TMI的twitch-api2 crate，实际上最终也打算覆盖大多数其他端点（见此问题）。因此，这个库目前仅提供了一种将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许可证下发布