WG APIは、APIの非常に詳細な説明を提供しますが、APIにアクセスするためのライブラリは提供しません。残念ながら、APIはモデルとメソッドを自動的に生成できる標準を使用していません。さらに、JSON応答は、応答の構造が原因でモデルの生成に失敗しました。その結果、モデル（特にメソッド）を手動で記述する方が簡単であることが判明しましたが、このレッスンは非常に日常的で退屈なものであることが判明しました。この記事では、HTML記述からモデルとクエリメソッドを自動化すること、および得られる利点と欠点を検討します。

開発

必要性がないため、WG APIとの戦いにはアプリケーションがありませんが、同時に、このAPIをデータへのシンプルでオープンなアクセスのためのさまざまなデモの例として使用したいと思います。残念ながら、.NETでWG APIの作業ライブラリが見つからなかったため、C＃でクライアントを生成するユーティリティを作成しました。これは、 WG APIサイトからドキュメントを読み取り、既製のリクエストおよびレスポンスモデルに処理します。

残念ながら、WG APIのドキュメントは完全ではなく、ある時点で、JSONを使用して既に受信した回答からのみ返される回答を理解することができます。

その後、 thunderspb habrozhitelはデータスキーマを取得するためのはるかに簡単な方法を提案しました。そのため、記事の公開を延期しました（時間の大幅な不足によりほぼ2か月）。残念ながら、このデータスキームにもまったく同じ欠点があります。複合データ型の応答形式を理解する方法はありません。将来、このデータスキームで動作するようにユーティリティをやり直す予定ですが、現時点ではWG APIでの動作は優先事項ではないため、現在実装されているものをレイアウトすることにしました。

実装：

WGが出口で要求を与えるものの構造を完全に文書化していないという事実のため、要求と応答の形式を実際には少し不便にする必要がありました。出力では、1つの答えと同じくらい簡単に取得できます。また、配列または辞書を取得することもできます。上記のように、リクエストを送信し、JSONの形式で応答を受信するだけで可能なことを見つけることができます。ここで、ライブデータでデータがどのように返されるかを確認します（ドキュメントに各メソッドのExplorer APIへのリンクがあると便利です。リクエストを作成して、ブラウザで直接回答を確認するのは非常に簡単です）。

最終的に、非常にシンプルなアプリケーションができました。このアプリケーションでは、WG APIが開いているページが開かれ、解析されます。その後、C＃クライアントコードが生成され、別のウィンドウに表示されます。

ここからソースコードをダウンロードできます。プロジェクトをダウンロードして実行する必要がない場合、または実行する機会がない場合は、そこに生成されたクライアントコードの例をダウンロードすることもできます。

使用例：

以下の例のソースコードは、ここから入手できます。

PCLと互換性のあるコードを入手したので、このコードをクライアントアプリケーションとWebサーバーアプリケーションの両方に使用できます。

たとえば、15分を費やし、デザインなしのテストXamarin Formsアプリケーションを作成しました。最初のフォームではニックネームによる検索を、2番目のフォームでは見つかったニックネームのうち選択されたニックネームに関する情報をスケッチしました。

作成したプロジェクトにcsファイルを追加し、ユーティリティで生成されたコードをコピーしました。

次のステップは、Json.netライブラリを追加することです（nugetからNewtonsoft.JsonライブラリまたはInstall-Package Newtonsoft.Jsonコマンドを検索します）。

検索コードは非常に簡単です。

var client = new WGClient.Client(); var accounts = await client.SendRequestArray<ResponseWgnAccountList>(new RequestWotAccountList() { ApplicationId = "demo", Search = SearchNickname }); GamerAccounts = accounts;

同時に、生成された説明のおかげで、コードを入力するときにスタジオで直接プロンプトを受け取ることができます。

ApplicationId：“ demo”はAPIのテストにのみ使用できることに注意してください。リリースするには、アカウントに ApplicationIdを作成する必要があります

見つかったニックネームのリストを表示するために残ります：

残念なことに、Amiev Sheriyev（私の兄弟）のおかげで、例のピースを引き裂くために提供されたゲームのニックネームに感謝しています。

見つかったリストからタップして、2番目のフォームを開き、選択したAccountIdを渡します。

 var item = e.SelectedItem as ResponseWgnAccountList; Navigation.PushAsync(new DetailsPageView(item.AccountId));

2番目のページでは、より詳細な情報を取得するための別のメソッドのリクエストも作成されます。

 var client=new Client(); var response=await client.SendRequestDictionary<ResponseWotAccountInfo>(new RequestWotAccountInfo() { ApplicationId = "demo", AccountId = accountId });

したがって、生成されたクライアントの助けを借りて、リクエストとWG APIへの応答を生成するルーチンの自動化にかかる時間を大幅に節約し、アプリケーション自体に時間、労力、注意を集中することができます。

短所：

手動ファイルカットの必要性

おそらくこれが最も基本的な欠点です-全体としての回答全体に関しては、サブタイプについては、データが返される方法に関する情報がありません（単純な回答、配列、または辞書）。したがって、多くの場所で編集を行う必要があります。

たとえば、テクニックメソッド（百科事典/乗り物）を取り上げます。

応答量を減らすために、1つのレベルと1つの国の手法を使用して応答をフィルタリングします。次のコードを呼び出すと、エラーがスローされます。

 var client = new WGClient.Client(); var response = await client.SendRequestDictionary<ResponseWotEncyclopediaVehicles>(new RequestWotEncyclopediaVehicles() { ApplicationId = "demo", Tier = "8", Nation = "ussr" });

例外を投げる：

未処理の例外：Newtonsoft.Json.JsonSerializationException：現在のJSON配列（たとえば[1,2,3]）をJSONオブジェクト（たとえば{"name"： "value »}）正しく逆シリアル化する。

このエラーを修正するには、JSONをJSONオブジェクト（例：{"name"： "value"}）に変更するか、逆シリアル化された型を配列またはListのようなコレクションインターフェイス（ICollection、IList）を実装する型に変更しますJSON配列からデシリアライズされます。 JsonArrayAttributeをタイプに追加して、JSON配列からデシリアライズを強制することもできます。

したがって、Crewサブタイプをデシリアライズすることはできなかったため、 API Explorerでリクエストをビルドすると、Crewが配列として返されることがわかります。

同時に、情報が存在しないクルーサブタイプとは対照的に、フィールドタイプ「整数のリスト」が指定されているという事実により、エンジンフィールドが正しく認識されました。

Crewフィールドを配列にして、フィールドを置き換えることでエラーを修正できます。

 ///<summary> /// ///</summary> [JsonProperty("crew")] public WotEncyclopediaVehiclesCrew Crew { get; set; }

配列ごと：

 public WotEncyclopediaVehiclesCrew[] Crew { get; set; }

default_profile.ammoについても同様のエラーがそれぞれ発生しますが、配列を作成して修正する必要があります。

残念ながら、ほとんどすべての方法でそのような変更を行う必要がありますが、それでも、これらの変更があっても、作業量は大幅に改善されます。

HTML依存関係

WG APIはJSON記述標準を使用しないため、HTML記述の解析に満足する必要があります。また、HTMLは任意に変更でき、同じタイプの記述は異なる場合があり、ロシア語でも見つけることができます。使用されるタイプの新しい名前が明日表示されないという保証はありません。

次のバージョンでは、JSONのHTML記述の代わりに解析しますが、この問題の影響はわずかに減少します。

ブラウザ

現在のソリューションはCefSharpに基づいています。これは、すでにソリューションがWin32プラットフォームでのみ機能することを意味します。 CefSharpライブラリを使用して書き換えて、クロスプラットフォームソリューションを取得できます。繰り返しますが、JSON解析に切り替えると、CefSharpの依存関係がなくなり、Windows、Mac、およびWebで動作するソリューションが作成されます。

悪いインターネット

パーサーは、インターネットがその後のすべての結果とともに消滅する可能性があることを考慮していません。

最適でないクライアントAPI

結局、私はかなり冗長であまり便利ではない重いバージョンに決めました。

 SendRequest<TResponse>(TRequest request)

ソリューションを簡単にする方法はたくさんあります。ただし、WGが独自のAPIの説明を完了するのが面倒ではない場合は、APIの最も簡単なバージョンを取得できます（つまり、応答としての要求から正確に何を期待できるかを、辞書、配列、または応答のルートおよび子ノードの単一オブジェクトを何らかの形で規制するため）。

NugetまたはJson.NETライブラリを手動で追加する必要性

残念ながら、現時点では、アセンブリまたはナゲットパッケージの形でソリューションを生成する方法はありません。これは、上記の問題（要求に対する応答の記述の欠如）のために完全に機能するコードをすぐに取得する方法がないためです。

Nugetパッケージを使用したソリューションでは、ソースコードをコピーしてJson.NETを手動で接続する必要がなくなる可能性がありますが、上記のように、所定の場所にファイルする必要があります。

テストカバレッジ

APIの新しいバージョンは月に1〜2回リリースされます。したがって、回答全体を再生成すると、すでに行ったファイルでのすべての編集内容が自動的に失われます。

新しいバージョンですべてがファイルで正しく変更されたことを確認するために、取得したソリューションをテストでカバーして、ファイルで何かを忘れずに忘れないようにすることができます。概して、テストは自動的に生成されます。理論的には、これにより、新しいバージョンがすべてを完全に破壊するわけではないことが部分的に検証されます。

コード品質

前述のように、コードはソリューションのプロトタイプとして作成されたものであり、実際のバージョンにスローして書き換えるのは残念なことではありません。ソリューション全体（合計15分で記述された例を含む）に、合計2晩が費やされました。

クライアントを生成するプロジェクトを選択する

現在、すべてのプロジェクトに対して4万行以上が一度に生成されています。クライアントが生成する必要があるプロジェクトとこのプロジェクトのメソッドの選択を追加できます。

現時点では、すべてのプロジェクトは名前空間で区切られているため、プロジェクトを削除するだけで最終的なアセンブリサイズを縮小できます。

余分なフィールドについても同じことが言えます。

無限に改善できますが、これは要約できます。

まとめ

Wargamingが開発者に開かれ、APIを開くだけでなく、フィールドの値を詳細に説明しようとしているという事実は非常に称賛に値します。説明と回答自体の構造には重大な欠点があります（つまり、返される内容、単一の回答、配列、または複雑な型の辞書を理解することは不可能です）が、これはそのようなサービスに最適なAPIドキュメントの1つです。

この記事で見たように、WGは少なくともいくつかの主要なプログラミング言語用のクライアントライブラリを簡単に生成でき、既成のライブラリを接続するだけで開発者の膨大な時間と労力を節約できます。 WGから同様のソリューションが見つかることを期待しましょう。

Wargaming APIのC＃クライアント生成

開発

実装：