For very large blobs, it's quite important to support an async API for uploading with support for continuing interrupted uploads (and downloads).
If you want to support that you could respond with a `202`, and two URLs, one to actually POST the data to, the other to GET the current upload status for that blob version. A flow could look like:
```sh
$ curl -s -X POST 'http://localhost:5555/ent/my/big.blob'
{
  "upload_url": "/ent/my/big.blob/1",
  "status_url": "/ent/my/big.blob/1/status"
}

$ curl -s -X POST --data-binary @mybig.blob http://localhost:5555/ent/my/big.blob/1 # blocks
$ [CTRL+Z]
$ curl -s http://localhost:5555/ent/my/big.blob/1/status
{
  "received": 12345, // bytes
  "total": 55555, // bytes
  "eta": 123122 // ms
}
```

Now imagine the network goes down and your upload is cut in half. You can use the information retrieved through the `/status` endpoint to resume the upload after the network is back.

```sh
$ curl -s -X PUT --range "12346-" --data-binary @mybig.blob http://localhost:5555/my/big.blob/1
```

PS: I am not sure `curl` supports `Content-Range` with that flag, but my point is illustrated here.