Replies: 1 comment
-
Interfaces like this are typically a server-stream operation, where the server sends back a stream of messages. Each message in the stream represents a chunk in the file. The request can indicate things like offset, so that the download can be restarted/resumed after an error. Something like so: syntax = "proto3";
service FileDownloadService {
rpc Download(DownloadRequest) returns (stream DownloadResponse);
}
message DownloadRequest {
// path, object ID, etc
string file_id = 1;
// >0 to resume a download, starting at given offset from start of file
int64 offset = 2;
// may want a version or etag so that a resumed download
// (where offset > 0) is certain to download the rest of the
// correct file, in case the file to download was mutated
// between the client's download attempts
// may also want to set a desired chunk size -- how much data the
// server should put into each message; larger chunks are more
// efficient when things are working, but may mean more
// retransmission in the face of errors and re-download attempts.
}
message DownloadResponse {
bytes chunk = 1;
} Using HTTP transcoding (like with connectrpc.com/vanguard), you could even expose something that looks like a traditional HTTP file download. That repo even includes an example to demonstrate this; here are links to the service interface and implementation. But if you were planning to use a Connect client (vs. some other plain HTTP user agent), it would likely be easier to implement a straight-forward service (like the example proto above) instead of using HTTP transcoding. |
Beta Was this translation helpful? Give feedback.
-
I want to implement a file download feature.
Beta Was this translation helpful? Give feedback.
All reactions