# データ取得API

この章では艦これを構成する様々なデータがどのように配信されるのか解説します。

## 2種類のデータ

データには大きく分けて2つの種類があります。 **マスタデータ**と**ユーザデータ**です。

マスタデータは基本的に**ログイン時にまとめて**取得し、 ユーザデータは**行動ごとに**必要なものを取得します。

ログイン時にロードで長時間待たされるのは、大量のマスタデータを取得するためだといえます。

## マスタデータ

[マスタデータのAPI](https://github.com/masarakki/IJN48/tree/master/spec/support/api/defaults/api_get_master)は全て `/kcsapi/api_get_master/` というURLの下にあります。 ログイン時に艦種、艦娘データ、装備、家具 などの固定データをひと通り取得します。 例外はマップに関するマスタデータで、これは出撃のたびに取得されます。

例えば艦種データを見てみるとid=1が海防艦だったり、戦艦が2種類あったり、 なかなか不思議なものを見た気になります。

### 艦娘マスタデータ

艦娘のマスタデータは、約50KBある巨大なデータです。 このデータにはやはり**不要なデータ**がたくさん入っています。 初期のデータはなるべく小さく、必要になった時点で他のデータを取ってくる設計にするとかなり小さくなるはずです。

例えば、全員分のドロップ時のメッセージが含まれています。 回数的に考えると、戦闘終了時のAPIレスポンスに毎回含めたほうが全体のサイズは小さくなると思います。

他にも図鑑で使うためか能力の初期値が全員分含まれていますが、これも図鑑にアクセスした瞬間に取得するべきです。 一回のログインで一度も図鑑にアクセスしない人のほうが多分多いんだから。

## ユーザデータ

[ユーザデータのAPI](https://github.com/masarakki/IJN48/tree/master/spec/support/api/defaults/api_get_member)は全て `/kcsapi/api_get_member/` というURLの下にあります。 所持している艦娘、装備、家具や艦隊の情報、レベルや資材の数などが取得できます。

### 艦娘データ

所持している艦娘が全て詰まったデータです。 1ページに表示されるのはたかだか20件くらいだったと記憶していますが、それでも全件取得します。 これを**提督の部屋に戻るたび**に毎回取得しに行きます。

艦隊編成画面の**ソート順**をグローバルに持っていて、その順でソートされたレスポンスが返ってきます。 艦隊編成画面でソート順を変更すると、**全部取得しなおし**です。

それぞれの[艦のデータ](https://github.com/masarakki/IJN48/blob/master/spec/support/api/defaults/api_get_member/ship.json)は

```javascript
{
  "api_member_id":32377,
  "api_id":2,
  "api_sortno":347,
  "api_name":"\u6dbc\u98a8\u6539",
  "api_yomi":"\u3059\u305a\u304b\u305c",
  "api_stype":2,
  "api_ship_id":247,
  "api_lv":77,"api_exp":349951,"api_afterlv":0,
  "api_aftershipid":0,
  "api_nowhp":15,"api_maxhp":30,
  "api_taik":[30,57],"api_souk":[49,49],"api_houg":[53,49], ...
}
```

のようなデータになっていて、これが全員分配列で並んだデータになっています。

見て解るとおり、`ship_id` が指定されているにも関わらず、 **艦娘のマスタデータを一切使わず**すべて冗長なデータになっています。 この中で必要なデータは**id, ship\_id, 現在のステータス値**だけであることは容易に解ります。 ソート順の変更も、**ソートされたidのリスト**でよいはずです。

### 武器データ

もっと凶悪なのが[武器データ](https://github.com/masarakki/IJN48/blob/master/spec/support/api/defaults/api_get_member/slotitem.json)です。 所持している武器を全て取得します。 艦娘の数とは比べ物になりません。 データサイズでおよそ6倍ありました。 武器を破棄が凄く遅いのは、破棄後に毎回このAPIが呼ばれるためです。

艦娘と同じように全て冗長なデータになっています。 武器は成長の要素がないので、**id何番の武器を何個持っている**というレスポンスで十分です。 たぶん現在のレスポンスを9割くらい削減できるのではないでしょうか。

## 初期化処理の最適化サンプル

初期化処理を最適化してみましょう。 まずユーザデータのうち、レベルや資材数は現状のAPIのままでよいでしょう。

ログイン直後にマスタデータを取得する必要はありません。 最短で提督部屋の画面を出すために、**秘書官のIDと内装のIDリスト**だけを返すAPIを作りましょう。 秘書艦のログイン時ボイスや、内装の画像は**IDからurlが決まる**ようにルールづけしましょう。 これだけで提督部屋の画面が出せます。たった数キロバイトで実現可能です。

その後おいおいマスタデータや他のユーザデータを取得するようにしましょう。

## まとめ: API改善ガイド

* とにかくデータ量を減らす
* データの分割・差分取得をする
* 冗長なデータを避け正規化する
* 非同期通信を活用する

中身のコードがわからないので正確なところはわかりませんが、 レスポンスの `svdata=` はおそらく**グローバル変数への代入**のような処理だと想像します。 つまり、APIのレスポンスを受け取るとグローバル変数が書き換えられることになり、 これを上手く制御して動かすには、通信が**逐次実行**であることが保証されてないといけません。

「複数のリクエストを同時に出し、返ってきたレスポンスから処理する」という非同期通信の強みが使えないことになります。 さらに、レスポンスを見て新しくリクエストを作ることも難しいので、「必要なデータがなかったら差分取得」みたいなコードも書きにくいのではないでしょうか。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://np-complete.gitbook.io/c86-kancolle-api/data.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.