2个版本

0.1.1	2020年11月10日
0.1.0	2020年9月25日

7 in #ttv-rs

在ttv-rs中使用

MIT/Apache

2KB

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 的 twitchchat crate 非常印象深刻，并希望其他所有模块都能模仿它的 API 并与之良好交互。例如，您应该能够为所有端点使用相同的异步执行器。

同样，我也是一个支持 sans-io 的库设计方法的粉丝，尽管如果库能够提供与其他库的集成选项来实际实现IO，对于最终用户来说会更好，这样可以减少样板代码。

正如我所说的，我的想法在很大程度上受到 Twitch4j 的设计启发；然而，我不会完全遵循它。我对事物应该如何组织也有自己的看法。

进度

活跃的Twitch API

特性	状态	当前实现
认证	… 测试	twitch_oauth2
聊天	… 测试	twitchchat
Helix	… 测试	twitch_api2（仅包含 `helix` 特性）
扩展	❌ 未实现	无
PubSub	… 测试	twitch_api2（仅包含 `pubsub` 特性）
Webhooks	❌ 未实现	无

已废弃的Twitch API

特性	状态	当前实现
v5 (Kraken)	❌ 未实现	（libtwitch-rs 目前与许可证不兼容）
遗留的Drop	❌ 未实现	无

非官方Twitch API

特性	状态	当前实现
TMI	… 测试	twitch_api2（仅包含 `tmi` 特性）
GraphQL	❌ 未实现	无

贡献

目前我主要在寻找关于我的愿景和想法的反馈和建议，以及可能适合此项目的现有crate。PR是欢迎的，但请注意，我对事物的组织和方法可能非常固执己见，而且目前可能会经常改变主意。

ttv-webhooks