2个版本

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

#5 in #ttv-rs

在ttv-rs中使用

MIT/Apache

2KB

ttv-rs

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

为什么？

这个crate集合的诞生源于创建一个“一库统治所有！”的愿望，以Rust语言与Twitch API交互。最初我以为每个子crate都可能依赖于crates.io上的不同已存在的crate，或者如果没有任何合适的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 包非常印象深刻，并且希望其他所有模块都能模仿其 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	❌ 未实现	无

贡献

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

ttv-v5