この記事は品川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が標準化されるかもしれません！

というわけで、みんなで利用して快適なファイルアップロードライフを過ごしましょう！