Pleroma狂信者たちの認識では「Mastodon APIドキュメントは仕様であり、必要な全てが定義済みで、仕様の範囲なら何をやってもいい」なんだと思う。当たり前だけどドキュメントは仕様ではないし全てが定義済みでもない。彼らが行った変更はソート順に関する挙動が既存の数値IDと異なるし、128ビットIDをいきなり導入してトラブルを起こさない訳がない。
@tateisu それ別に狂信者じゃなく、丼と互換性あるもの作ると必然的にそうなると思いますよ。ドキュメントにstringと書いてるのに裏の挙動に依存する方が危ういと思いますよ
@valerauko 事前にアプリ開発者と協調してればこうはならなかったよ。あと繰り返すけどドキュメントは仕様ではない。 まあさっき仕様に明記するPRかいて通ったので、IDの扱いに関する議論はもう出ないけども。 https://source.joinmastodon.org/mastodon/docs/merge_requests/18/diffs
@tateisu 否定しません。そういうコミュニケーションって社内でさえ難しくてossなおさら。ドキュメントが仕様として成り立つとありがたいですね
@valerauko 誰がそのコストを払うの、という話です。特にAPIドキュメントの更新は外野からのPRが主です。
@tateisu 外部公開api作ると仕様も合わせて公開するのは俺の中で当たり前です
@valerauko まずAPIを作ってるのは俺ではないので、そうですか、としか…。
@tateisu 丼のapi適切に仕様まとまってなけりゃそれは丼が悪いってことです
@valerauko 今回の話だと「互換APIを作りたい」人の調査不足が主な理由でしょう。想定されてない使い方に対して「仕様がまとまってないのが悪い」は筋がおかしい
@valerauko IDの発行なんて普通のAPI利用者はしないわけですよ。サーバが発行したIDを使う。IDの発行に必要な定義がアプリ開発者向けのAPIドキュメントにないからといって「仕様がおかしい」というのは変です。