-
Stripe APIのバージョニングの仕組みと、真似すべき点
Stripe APIは、アカウントごとに日付付きバージョンを固定し、リクエストごとに上書きもできる。その仕組みとWebhook、コスト、真似すべき点を解説する。
APIの変更1分で読めます
-
Protobufの破壊的変更：ワイヤー上で生き残るもの
Protobufの破壊的変更は、URLではなくワイヤーフォーマット上で起きる。安全なフィールド変更と、全クライアントを静かに壊す変更の違いを説明する。
APIの変更1分で読めます
-
バージョン番号のないGraphQLの非推奨化
GraphQLにはURLにv1やv2がなく、フィールドはディレクティブで一つずつ非推奨化される。破壊的変更の定義、受信者の把握、安全な削除時期を説明する。
APIの変更1分で読めます
-
API移行ガイドをどう書けばいいか、その方法
API移行ガイドは、互換性のない変更を障害ではなくチェックリストに変える。何を含め、誰がいつ書くか、チェンジログだけでは足りない理由を説明する。
APIの変更1分で読めます
-
社内向けAPIチェンジログ：他チームにとって何が変わるか
公開APIと違い、社内向けAPIチェンジログには二フロア先の読者がいる。この違いの由来、呼び出し側の台帳を誰が持つか、実務での対応を説明する。
APIの変更1分で読めます
-
APIのSunsetヘッダー、それを送るべきタイミング
APIのSunsetヘッダーは、バージョンがいつ応答を止めるかを機械可読な形でクライアントに伝える。RFC 8594の定めと、ブラウンアウトの利点を解説する。
APIの変更1分で読めます
-
Webhookチェンジログ、誰も求めなかった破壊的変更
Webhookのペイロード変更は、受信側が拒否できないため静かに壊れる。破壊的変更の定義、ペイロードのバージョニング、受信者の把握と安全な移行を扱う。
APIの変更1分で読めます
-
APIチェンジログ: 何を公開し、誰が読むのか
APIチェンジログの読者は、自分のコードが来月も動くかを知りたい人だ。各エントリが負うべき内容と置き場所、開発者が購読する方法を説明する。
APIの変更1分で読めます
-
開発者を失わずにAPIを非推奨化する方法
非推奨化は、日付の付いた一つの約束だ。具体的なスケジュール、通知テンプレート、レスポンスヘッダー、サンセットを事故にしないための決定的な一手を説明する。
APIの変更1分で読めます
-
呼び出し元のためのAPIバージョニングのベストプラクティス
壊れるものだけをバージョン管理し、呼び出し元に見える場所へ置き、古い版も期日まで動かし続けよう。代表的な四つのスキームを長所と短所で比較する。
APIの変更1分で読めます
-
破壊的変更に該当するものと、安全な出荷方法
破壊的変更とは、正しい呼び出し元が耐えられない変更のこと。何が該当し何が該当しないか、CIでの検出方法、安全な出荷の手順を解説する。
APIの変更1分で読めます
