PHP によって開発された API マルチバージョン管理プラクティス

発生した状況

この記事は、モバイル インターネット クライアントが古いバージョンとの互換性を必要とする状況を対象としており、アプリの最新バージョンへの強制アップグレードは説明されていません。

bugtags.com プロジェクトでは、ビルドは次の仕様に従っています。
1.0.1
大きな機能。バグ修正
バージョンリストは次のとおりです:

1.0、1.1、1.2、1.3、1.4
2.0、2.1、2.2 、2.3
3.0、3.1
…
5.0

このようなバージョン構成では、スパンが最大の場合、1.0 ユーザーと 5.0 ユーザーが共存する必要があります。
/api/user/info インターフェイスを例に挙げます。非常に多くのバージョンで反復を行った後、バージョン 1.0 と 3.0 では返されるデータ構造が完全に異なる可能性があります。
このようなシステムでは、完全なバージョンのアーキテクチャをどのように設計するかが非常に重要です。

困難を理解する

モバイル インターネットは従来の Web 開発とは異なります。従来の Web 開発と比較すると、反復とバージョン アップグレードが迅速であるため、次のような問題があります。

ユーザー獲得の難しさと維持率の低さ

クライアントのアップグレード コストが高い、一部のユーザーはアップグレードを拒否します

サーバー側コードの複数のバージョンはサイズが大きく、メンテナンスコストが大幅に増加します

アーキテクチャの目的と要件

簡素化されたバージョン管理プロセス、簡単な構成管理

サーバー側の PHP コードのサイズを削減します

お試しください新しい要素を導入しないようにします

WeChat グループでのディスカッション

リクエストフォーム同意書

v1.api などのドメイン名を使用します.bugtags.com インターフェイスのバージョンを区別します

URL の pathinfo にバージョン情報を入力します (api.bugtags.com/v1/

api.bugtags.com/user/1?_ver=1.0.1

API_VER: 1.0.1

などのバージョン情報を http ヘッダーに配置します。バージョン番号にドメイン名を使用することは、あまり認識されていない解決策です。主な理由は、ドメイン名の管理が部門を越えて行われることが多く、通信コストが増加することです。

http ヘッダーは、URL をクリーンに保つための私のお気に入りの方法です。

url パラメーターにバージョン番号を運ぶ方法も良いですが、ビジネス ロジックのパラメーター名が重複しないように注意してください。

コードを管理する 2 つの一般的な方法

Git/svn タグ管理方法

利点は、特に git がコードを管理する場合、いつでもブランチを切り替えることが低コストであることです。

欠点: 複数のバージョンを変更する必要がある場合、コードをマージする作業負荷が大きくなります。

分岐は 1 つだけであり、コード内のバージョン情報に基づいて判断されます

利点、コード全体のサイズが小さい (コードのコピーが 1 つだけ)

デメリット、バージョン判断が必要な箇所がある 分岐文が多い

私がまとめた解決策

最終的な解決策は、PHP のオートロード読み込み機構と名前空間を最大限に活用しています。

ベースはすべてのビジネスの基盤であり、最初のバージョンであり、ライフサイクルが最も長いバージョンであると仮定します。

v10 は、ビジネス ポイントでのバージョン ロジックの判断を最小限に抑えるために、バージョン

1.x.x

用のサービスを提供しますが、完全に拒否するわけではありません。

v20/v30 は v10 バージョンに基づいて開発されています

v40 バージョンは v30 バージョンに基づいて開発されています

例

v10 は 3 つのインターフェース a、b、c を提供します

v20 は 3 つのインターフェース a1、b、c を提供します、a1 は av30 が提供する 3 つのインターフェイス a、b1、c があり、b1 は b の変更です

具体的に説明するには、次の 3 つのコードを使用します

構成バージョン:

ベース ディレクトリ ベース公開コードの大部分を保存します

• バージョン ディレクトリ v10/v20 はバージョン ディレクトリであり、このバージョンと基本バージョンの間の異なるロジックを保存します

• バージョンの違いは上記のように最小粒度としてファイルに基づいています 3つのコードが見られます。

• ユーザーは /api/user/info?ver=3.0.1 にアクセスしたいと考えています。この時点で、クラスのロード順序は次のとおりです。

v30 で試してください Config.php のロードに失敗しました

v10 で Config.php のロードに失敗しました

Base で Config.php をロードしようとしました成功しました

関連するロジックを実行します

継承を 1 レベルのみに制限しているのは、システムの複雑さをできるだけ軽減するためです。可能。このコード管理方法は、いくつかのプロジェクトで実証されています。システム コードの複雑さは、特に複数のバージョンが繰り返されるシステムでは大幅に軽減でき、強制的にアップグレードする必要はありません。もう 1 つ注意すべき点は、次のとおりです。

このメソッドを使用して読み込みを処理する場合、いくつかのバージョンの沈殿の後、共通部分は徐々に BASE バージョンに沈殿する必要があります

リリース システムにファイル削除機能があることが最善です。そうしないと、部分的に削除された後も、上位バージョンで上位バージョンのコードが引き続き使用されます。

作者は、アプリ開発者のテスト効率を大幅に向上させる SDK 製品である bugtags.com を開発、運用しています。ご利用、転送、推奨を歓迎します。

私たちのチームは長い間 PHP バックエンドを探していました。ご興味がございましたら、次の公式アカウントを追加してください: