ファイルアップロードAPIの設計について考えてみる
はじめに
株式会社 Rehab for JAPAN の開発チームに所属している徳永です。
現在、新しいプロジェクトの Backend を担当しており、API の設計や実装を行なっています。
業務の中で必要になったためアップロードする API を実現する方法(メリット・デメリット)を改めて考えてみました。
なお、弊社では REST API を採用しているため、本記事では REST API を前提として検討しています。
また、合わせて世の中の API でどのようなパターンで実装されているかブログ記事と公開されている API ドキュメントをベースに調査してみました。
対象読者 (ターゲット)
- REST API の設計に興味がある人
- ファイルアップロードの実現方法に興味がある人
ファイルアップロードの方法について
FE と BE を分離して開発する場合、大きく3パターンがありそうです。
以降では、それぞれのパターンについて簡単に説明してみます。
パターン(1) multipart/form-data を利用して実装するパターン
こういった用途に良さそう:
ファイルのアップロードがメインのユースケースの場合
こういった用途には向かなそう:
ファイルのアップロードと合わせて、構造的なテキストデータ(一定の階層を持つ必要がありそうなケース)では保存したい場合にはあまり向かないかもしれません。
パターン(2) JSON でファイル内容を base64 エンコードを利用して実装するパターン
こういった用途に良さそう
JSON でリクエストを受信するため、構造化されたテキスト情報とアップロードするファイルを保存したい場合
こういった用途に向かなそう:
大きいファイルサイズのアップロードが必要な場合 Base64 に変換することでファイルサイズが 30 パーセント程度大きくなってしまうため動画ファイルのような一定サイズ以上のファイルをアップロードする際には別パターンを検討した方が良さそうです。
パターン(3) パターン(1)とパターン(2)のハイブリッドパターン
こういった用途に良さそう:
大きいファイルサイズの保存および構造的なテキストデータの保存が同時に必要な場合。
こういった用途に向かなそう:
画像データとテキストデータを1つのトランザクションでまとめたい場合には向いてなさそうです。
まとめ
ファイルアップロードの実現方法にはいくつかのパターンを整理してみました。実際の開発では要件が異なるため、それぞれのパターンを使い分けること、またそのための引き出しとなる実現パターンを理解しておくことが重要だと感じました。
また、実際の要件に合わせてパターンをカスタマイズすることなども適宜検討してもらえればと思います。
世の中のアップロード API がどのようなパターンで実装されているかを調査することで、自身の知識を整理することもできました。
本記事が ファイルアップロードの API 設計をする際に何らか参考になりましたら幸いです。
Discussion