0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

protobuf.devのAPI Best Practicesを読んでいく全部俺Advent Calendar 2024

Day 18

API Best Practices ~リクエストとレスポンスのサイズを制限する

Last updated at Posted at 2024-12-17

リクエストとレスポンスのサイズを制限する

リクエストとレスポンスのサイズは制限すべきです。
8MiB程度の制限を推奨し、多くのプロト実装が壊れる2GiBはハードリミットです。
多くのストレージシステムはメッセージサイズに制限があります。

無制限のメッセージは

  • クライアントとサーバーの両方を肥大化させる
  • 予測できないレイテンシーを引き起こす
  • 単一のクライアント・サーバー間で長時間接続が発生し耐障害性が低下する

API内のすべてのメッセージを制限する方法はいくつかあります。

  • 各RPCを論理的に独立し境界付きメッセージを返すRPCを定義する
  • 無制限のクライアント指定オブジェクトリストではなく、単一のオブジェクトに対して操作するRPCを定義する
  • 無制限のデータを文字列、バイト、または繰り返しフィールドにエンコードしないこと
  • 明示的に長時間かかるRPCを定義します
    • 結果をスケーラブルで同時読み取り用に設計されたストレージシステムへ保存します
  • ページングAPIを使用する
  • ストリーミングRPCを使用する

UIを構成済みの場合、小さなデータを操作するメソッドを作成しクライアントがそれらの複数RPCをバッチ処理してUIを構成することを期待するも参照してみてください。


方法について、個人的に思う具体的な方法を補足してみたい。

  • 各RPCを論理的に独立し境界付きメッセージを返すRPCを定義する
    • preloadしすぎない
  • 無制限のクライアント指定オブジェクトリストではなく、単一のオブジェクトに対して操作するRPCを定義する
    • ListではなくGetで賄えないか検討する
  • 無制限のデータを文字列、バイト、または繰り返しフィールドにエンコードしないこと
  • 明示的に長時間かかるRPCを定義します
    • 結果をスケーラブルで同時読み取り用に設計されたストレージシステムへ保存します
      • 非同期処理を検討する
  • ページングを使用する
  • ストリーミングを使用する
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?