2.0 KiB
BUD-05
Media optimization endpoints
draft optional
Defines the PUT /media endpoint for processing and optimizing media
PUT /media
The PUT /media endpoint MUST accept binary data in the request body.
The server SHOULD perform any optimizations or conversions it deems necessary in order to make the media more suitable for distribution.
Clients SHOULD include Content-Type and Content-Length headers specifying the MIME type and size of the data. Clients MAY provide an X-SHA-256 header containing the lowercase hex-encoded sha256 of the request body. A server MAY use this value to enforce rejection policies or perform authorization checks prior to persisting the blob.
On success, the endpoint MUST respond with a 2xx status code with a Blob Descriptor in the response body.
On failure, the endpoint MUST return an appropriate 4xx status code and an error message explaining the reason for the rejection.
Upload Authorization
Servers MAY require authorization when processing media as defined by BUD-11.
HEAD /media
Servers MUST respond to HEAD requests on the /media endpoint in a similar way to the HEAD /upload endpoint defined in BUD-06
Limitations
The goal of this endpoint is to provide a simple "trusted" optimization endpoint clients can use to optimize media for distribution. How the blob is optimized is the sole responsibility of the server and the client should have no say in what optimization process is used.
If a longer optimization or transformation process is needed, or if the client needs to specify how a blob should be transformed, other protocols should be used.
Client Implementation
Clients MAY let a user selected a "trusted processing" server for uploading images or short videos.
Once a server has been selected, the client uploads the original media to the /media endpoint of the trusted server and get the optimized blob back.
Then the client can call the /mirror endpoint on other servers to distribute the blob.