이 문서는 시나가와 Advent Calendar 2019의 15 일째입니다.
tus를 사용해보고 훌륭함을 깨달았으므로 공유하려고합니다.

tus는 무엇입니까?

htps : //개 s. 이오/
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인 구조를
간단하게 구축할 수 있는 점입니다.
5g g D 리브 이나 Dropbox 도, 같은 구조를 자전으로 개발해, 세상에 널리 API를 공개하고 있습니다만, 이들 둘 다 대잡하게 쓰면,
아래의 순서와 같이 클라이언트로부터 한 번 메타데이터를 보내고 응답으로 받은 ID와 엔드포인트
파일을 청크마다 업로드해 가는 형태로 되어 있습니다.




이것에 상당하는 기능을, OSS로서 제공하고 있는 것이 tus의 포인트입니다.

또한, 프로토콜을 정의하고 있기 때문에,이 구현이 퍼져 나가는 것으로,
현재는 서비스마다 화려한, 세상의 파일 업로드 API가 표준화될지도 모릅니다!

그러므로 모두 이용하여 쾌적한 파일 업로드 라이프를 보내자!