1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 公開Web APIが Product API のような名前と /api/v1 パスを同時に使うと、API自体のセマンティックバージョンと構造がずれる可能性がある
  • /v1/ パスと major.minor.patch を併用すると、ルート とAPI契約が混ざり、セマンティックバージョンの最初の数字がURLに固定される
  • 互換性を壊す変更には新しいパスと リバースプロキシ のルートが必要になり、契約情報がURLとバージョン番号に分散する可能性がある
  • 後続APIを同時に作ると既存APIは事実上 v1 に縛られ、その後の互換性破壊的変更で名前とパスの意味が曖昧になる
  • 公開Web APIのバージョン管理において、繰り返し気になるやり方と、より良い 設計原則 を探そうとする問題意識である

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rs の意見
  • URL に /v1/ を入れるのは、実際には大きな利点のひとつ。エンドポイントを停止するまでは、利用者に API を壊さないことを強制できるから

  • Evolving HTTP APIs と、同じ著者によるそのほかの記事も有用な助言を与えてくれる

  • 基本的には各ルートに /v1//v2/ のように付けて 互換性を壊す変更 を示す。複数ホストで動く標準を定義しようとしているのでなく、公開運用 API であれば、完全な semantic versioning を行う理由はあまりない
    semantic versioning は、ほかの開発者が変更ログを 20 分も読まなくても、安心して依存関係を更新できるようにするために存在するが、運用中の API では人々は新しいマイナーバージョンやバグ修正バージョンをいつ取り込むか選べない
    何が互換性を壊す変更かは、文書化された挙動 を変える場合や、文書化された挙動に依存する既存クライアントを壊す場合だと考える。文書化されていない挙動の変更まで破壊的変更とみなすところもあるが、そこには多くのリスクがある

  • Google ではこうしている: AIP-185: API Versioning, AIP-180: Bacwards compatibility
    これらの設計文書は Google の仕事の進め方にかなり特化しているように感じるが、API を設計するときの参考にしてきたし、その中のいくつかのアイデアはとても有用だった

  • 一般に、すべての API は 互換性を壊す変更 をできるだけ減らすよう努めるべきだと思う。たとえばプロパティ名を変えたいなら、既存のプロパティをなくすより、新しい名前を重複して追加するほうがよい
    ただし、the people at Buttondown do it のやり方もきれいだ。API バージョン間のマイグレーションを定義して、利用者はヘッダーで自分の API バージョンを固定でき、提供者は変更を継続的に進められるようにする

    • 出力プロパティでは、プロパティを重複させる方式はかなりうまく機能した。ただし入力では、クライアントが 2 つのプロパティに異なる値を送ってくる場合を処理しなければならない
      「常に新しい名前を優先する」という答えを思いつくが、クライアントが読み取り→修正→書き戻しの順序で動作し、サーバーが作成したオブジェクトの修正版を再送する場合には破綻しうる。クライアントが古いプロパティだけを更新し、新しいプロパティは無視したまま送り返してしまうことがあるからだ
    • API 提供者が説明しているように、API バージョン間の マイグレーション を提供するのはよさそうだが、using an HTTP request header for versioning can cause problems
    • そのリンクは データ形式 をどう扱うかをとてもよく説明している。ただ、それは一部にすぎず、挙動そのものが変わるときにどうするのかが気になる
      その変換を挙動の割り当てにも使えそうだが、見落としていなければ、その点は扱われていなかった
  • 理想的には、バージョンをパスに含め、新しいバージョンには追加的な性質を持たせるべきだ。そうすれば、古いバージョンの API は必要な入出力変換を経て、リクエストをより新しい API バージョンへ 再ルーティング できる
    数年後に古いバージョンを誰も使わなくなれば削除でき、/v1/ パスはエラーになる

  • 以前、Accept ヘッダーによる コンテンツネゴシエーション で API バージョニングを行う方式を少し読んだことがある。そういうやり方で API バージョニングをしたことがある人がいれば、経験を知りたい
    私の経験では、リソース単位のバージョニングやグローバルなバージョニングが最も直感的な方式に近かった。廃止には Deprecation HTTP レスポンスヘッダー(RFC 9745)を使い、最終的には古いエンドポイントに 410 Gone のようなレスポンスを返す組み合わせが、クライアントを新バージョンへ移行させるための妥当な方法に思える
    さらに、誰かが 進化可能な API を作ったことがあるのかも本当に気になる。古いバージョンへのリクエストを内部で新しい API バージョンへのリクエストに変換し、クライアントが移行するか一定時間が過ぎたら、実際に古いバージョンを削除するというやり方のことだ