古いAPIを廃止する

そもそもそのAPIが使われているのか使われていないのかの判断ができない

自社サービス内だけで使っているとしても、clientが複数存在する場合、調べるのが困難

そこにアプリなども含まれていると更に難しい

過去のversonを触っているユーザがまだ存在する可能性がある

アクセスログを見るとか

明確に移行した場合は、「何月何日に使わなくなった」というのをどこかにメモったりしないといけないかも

その1年後に消す、みたいな運用するとか

誰も使っていないAPIの実装が残り続けているとリファクタリングが困難になる

無意味にlibraryのversion追従に対応したり、依存関係を考慮しながら実装したり

gpt-4.icon

HTTPステータスコード303は "See Other" を意味します。このステータスコードは、リクエストに対するレスポンスが別のURLに存在し、GETメソッドでそのリソースにアクセスするべきであることをクライアントに通知します。

一部のシナリオでは、廃止されたエンドポイントが新しいエンドポイントにリダイレクトされるために303ステータスコードが使用されることがあります。しかし、このアプローチは常に理想的なわけではありません。なぜなら、これはクライアントが自動的に新しいエンドポイントを使用するようになることを意味し、それが新しいAPIの仕様に完全に準拠しているとは限らないからです。

したがって、303ステータスコードを使用することは、古いAPIから新しいAPIへの移行を強制する一方で、新しいAPIの仕様に完全に準拠していないクライアントが発生する可能性があるというリスクを伴います。このため、通常は先に述べたような方法（ドキュメンテーション、警告ヘッダー、またはAPIのレスポンスメッセージによる通知）を通じて開発者に旧バージョンのAPIの廃止を通知し、新しいバージョンへの移行を促すことが推奨されます。

エンドポイントの棚卸し

脱線が多くて長い

思ったより力付くで微妙だった

フロントエンド側は、fetch時の書き方を特定してコード内に残存しているURLを一覧する

それを比較するというだけ

この解決策は、モノレポのWebサービスだからできるだけ

だし、RSCとか使えばもっと単純に解決できる

もっと難しいのは、

1つのサーバが複数のclientから呼び出されている、とか

アプリからも呼び出されており、古いバージョンを使っているユーザが存在しうる

という状況でどうするかなんだよな

最新のコードベースを比較するだけならまあ