APIオブジェクトとサブオブジェクトを設計するときに考慮すべき理想的な応答サイズは何ですか
ローカルで実行している場合、すべてのAPIリクエストが50ミリ秒以内に応答する必要があるというパフォーマンスメトリックを使用しています。 Githubs API の平均応答時間からこれを取得しています。
Fooというオブジェクトがあります。 jsonとしてシリアル化すると、1つのFooに6KBのテキストが含まれる場合があります。
Fooには、Barと呼ばれる約3KBを構成するサブオブジェクトがあります。
私のAPIには、一度にFoosのページを返すエンドポイントがあります。例：
https：// apidomain/v1/foos？pageSize = 25
25 Foosの単一ページに対する応答は、約150KBです。ローカルで実行すると、応答に75msかかります。
バーをFoosオブジェクトから取り出して、次のようにサブオブジェクトとして使用できるようにするデザインオプションがあります。
https：// apidomain/v1/foos/fooId123/bar
これにより、25 foosの単一ページに対する応答が75KBに減少します。そのfooのバーを取得するために追加のリクエストが必要です。これにより、平均応答時間が目標の50ミリ秒に近づきます。
RESTful APIとそのオブジェクト定義を設計するとき、50msが理想的な応答timeである場合、理想的な応答sizeは何ですか？
APIオブジェクトとサブオブジェクトを設計するとき、他にどのような考慮事項がありますか？
mean応答時間とabsolute応答時間を区別することが重要だと思います。リンク先のメトリックスページによると、それはまさにGitHubが行うことです。応答時間に関する2つの指標を追跡します。
- 平均（平均）
- 98パーセンタイル
これは2つの図を提供します。ほとんどの人が対処する応答時間と、ユーザーが対処する最悪の応答時間です。
次の質問は、応答時間をどこで測定するかです。 Webサーバーのアクセスログから応答時間を測定する場合（ほとんどの人がそうするように）、要求が受信されてからサーバーが応答を送信するまでの差分を測定しています。転送時間は含まれません。ブラウザーの開発者タブ内から応答時間を測定する場合、要求を送信してから応答が完全に受信されるまでの時間を測定しています。これには、タイミングに2回のネットワークトリップが含まれます。
ネットワーク時間の最小化
データ転送時間を改善するためにできることはほとんどありません。通常、ネットワーク速度は、制御できない場所で制限されます。ただし、次のことは可能です。
- HTTP圧縮 を有効にします。 JSonとXMLは非常に圧縮性が高いため、費用も節約できる可能性があります。
一貫したメトリック
何を測定しているのか、なぜこれらのメトリックが存在するのかを確実に把握してください。私たち人間は、100ミリ秒（1/10秒）未満の時間差を認識できないことに注意してください。
ニーズに合わせて設計
必要なものを中心にAPIを設計します。何かが実際のボトルネックになった場合は、そのときにどのように改善または最適化できるかを確認できます。
- 完全なペイロードを必要とするクライアントがある場合は、その完全なペイロードのAPIエンドポイントを用意します
- 省略されたペイロードを必要とするクライアントがある場合は、その省略されたペイロードのAPIエンドポイントを用意します
- 絶対データサイズについては考慮しないでください。実際のニーズについて考えます。適切なデータセットを返すと、API呼び出しが最小限になります。
一般的には、要約データのリストが必要であり、ユーザーが情報にドリルする準備ができたら、完全なペイロードを要求します。
あらゆるリクエストの理想的な応答サイズは、クライアントが必要とするすべての情報を含む可能な最小のサイズです。クライアントに複数のリクエストを行わせることは非効率的であり、避ける必要があります。
情報の異なるサブセットを必要とする複数のクライアントがあり、2つの要件が対立するように送信するようです。クライアントAが複数のリクエストを行うのを防ぐために、クライアントBが必要としないデータを送信する必要があるようです。しかし、できることは必要な情報のサブセットを指定するオプションをリクエストに含めるです。次に、クライアントAが接続すると、バーが含まれているfoosを要求できますが、クライアントBは、バーがなくても構いません。
例として、GoogleのいくつかのAPIをご覧ください。これはよく行われます。