2 个版本

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

#2 in #某种程度上

MIT/Apache

17KB

ttv-rs

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

为什么？

这个crate集合的诞生源于创建一个“一个库就能统治一切！”的库来使用Rust与Twitch API交互的愿望。最初我认为每个子crate可能都会依赖于crates.io上不同的已存在的crate，或者如果没有合适的crate，就会自己实现这些功能。然而，自从我开始这个项目以来，我意识到我最初认为只打算覆盖Helix和TMI的[twitch-api2](http://crates.org.cn/crates/twitch_api2) crate，实际上最终也打算覆盖其他大多数端点（参见[这个issue](https://github.com/Emilgardis/twitch_api2/issues/27)）。因此，这个库目前只提供了一种方法，可以在一个依赖中组合[twitchchat](http://crates.org.cn/crates/twitchchat)和[twitch-api2](http://crates.org.cn/crates/twitch_api2)，名称更短 😛

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

目标

涵盖Twitch文档中列出的所有API
涵盖现在已知或未来发现的几个有用的[非官方端点](https://thomassen.sh/twitch-api-endpoints/)
尽可能接近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目前不兼容许可证）
旧版Drops	❌ 未实现	无

非官方Twitch API

功能	状态	当前实现
TMI	… 测试	twitch_api2（仅带有`tmi`功能）
GraphQL	❌ 未实现	无

贡献

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

许可证

MIT和Apache 2.0许可证