この記事は品川Advent Calendar 2019の15日目です。
tusを使ってみて素晴らしさに気づいたので、共有しようと思います。
tusって何よ？
https://tus.io/
RESTfulなAPIでファイルアップロードを可能にするOSS。
サーバサイドの実装（デーモン）や、クライアント（jsやpython）が
これらを繋ぐプロトコルを定義しています。
データ保存先にAWS S3を使えたり、アップロード前後に処理を加えたり、
カスタマイズが比較的用意にできるため、拡張性高めのソフトウェアになってます。
よーし、この製品を使って、RESTfulでresumableなファイルアップロードライフを送れそうだぞ！
とはいえ国内での利用した実例記事が少なすぎるので、まずは簡単な紹介記事を上げてみます！
そもそもファイルアップロードってどんなのがあるの？
RESTfulなAPIでファイルアップロードをしようとすると、大きく下記の2パターンがありますよね。
ただ、これらのどちらも、REST-APIに組み込むにはデメリットが存在しているんです。
base64
ファイルの中身をbase64エンコードし、リクエストボディに詰め込む方法。
エンコードした文字列をJSONに詰めれるなど、REST-APIに親和性が高い。
デメリット
エンコード時に大体133%くらいのサイズ感になっちゃうので、システム性能に一番効く（であろう）
NWコストがかかってしまう。
multipart/form-data
20年以上前に確立され、RFC2388で定義され世の中のデファクト的存在。
デメリット
JSONが生まれる前にできた仕様なので、JSONベースのREST-APIには親和性が無い
じゃあtusd使うと何が嬉しいの？
REST-APIで、途中で通信が途切れてしまっても、次回その時点からアップロード再開できるresumableな仕組みを
簡単に構築することができる点です。
GoogleDriveやDropboxも、同様の仕組みを自前で開発し、世に広くAPIを公開しておりますが、これらのどちらも大雑把に書くと、
下記のシーケンスのように、クライアントから一度メタデータを送付し、レスポンスで受け取ったIDなりエンドポイントなりに対して
ファイルをチャンク毎にアップロードしてゆく形になっています。
これらに相当する機能を、OSSとして提供しているのがtusのポイントです。
更に、プロトコルを定義をしているので、この実装が広がってゆくことで、
現在はサービス毎にバラバラな、世の中のファイルアップロードAPIが標準化されるかもしれません！
というわけで、みんなで利用して快適なファイルアップロードライフを過ごしましょう！