Shinya

@yanorei32 PRでも書きましたが、更新された最新のOpenAPI定義や実ソースをもとにドキュメントを自動生成してデプロイするのがベストです。説明などの情報も自動生成するなら断然OpenAPIのマニフェストを使用すべきですね。

追記: いろいろとエンドポイントを見ていると、パラメータの説明が付与されているエンドポイントも存在する。

#222 と関連。 こうしたjson5ファイルで使用できる `description` といったフィールドは全て明文化されるべき。そうでなければコントリビューターの不要な調査が必要になる。

@syuilo シングルクオートで修正しましたが、ほぼ新規扱いになりました 🤔

@yanorei32 @syuilo なるほど、そうなるとまずドキュメントを作るための環境と標準が整備されていないのが問題でしょう。 私はVSCodeで編集していますが、このリポジトリのためだけに私のVSCodeの設定を自分で変更したくないです。また、ドキュメント中にUnionTypeやOptionalを埋め込む方式もどこにも明文化されていません。 そもそもなのですが、頻繁に変更されるAPIなのであれば、なおさら実ソースからjson5ファイルやMarkdownを生成するジェネレータを作るべきですね。簡単に作れると思うので、検討してみてください。

@syuilo あと、この際なのでついでのリクエストですが、個人的にはMisskey APIのエンドポイントに関するドキュメントはちょっと使いにくいです。 というのも、例えばエンティティのフィールド情報などが最初に畳まれた状態なので、中身を見るのにいちいちクリックしないといけないです。もっとシンプルにできないものでしょうか？ まずは抜本的にドキュメントの構造をリファクタリングすることで、 @yanorei32 が示した改善もしやすくなると感じます。

@rinsuki 返信ありがとうございます。 Misskey APIのページングの仕様がまだよくわかっていないので恐縮ですけど、 少なくとも対象のエンドポイントが `notes` の場合は `https://xxxx.io/api/notes` までは不変なのではないでしょうか？

@rinsuki なるほど、ページングと経緯については理解しました。 たぶん `notes/hybrid-timeline` と `notes/global-timeline` のような扱う対象が同じでスコープが異なるエンドポイントで差分を見てみたいということだと思います。 それを聞いた上でそもそもなのですが、 このAPIコンソールは「特定のエンドポイントを実際に叩いてどういうJSONが返ってくるか」 というお試し用途以上のことを想定しているということですかね。 少なくとも今の仕様だとユーザーがエンドポイント文字列を操作できるので、 今いるエンドポイントページ以上のことができてしまうのが少し気持ち悪いと感じました。 ただその仕様を残したいということだと、 ユーザーが下手に入力した文字列をリセットするためのボタンを用意するというのも一つの手だと思いますね。

Hi @guidomz Of course this is possible! Bluesky's link card metadata is returned from https://cardyb.bsky.app, so I just would add an option like `--link-card-url`.

Hi @michaelmhoffman, thanks for your feedback! Yes this feature of bluesky_cli is indeed incomplete and has much room for improvement. I plan to make more radical improvements including this