3 ms·
1. The bucket is the domain. If you have a self hosted, single tenant minio instance, you might not need buckets, it doesn't really hurt you to just set up one
by thayne 4y ago
1. The bucket is the domain. If you have a self hosted, single tenant minio instance, you might not need buckets, it doesn't really hurt you to just set up one bucket, but for people that do need buckets, it would be a lot more difficult to build them on something that didn't have a similar concept.
2. I'm with you on this one. At least as long as it is over https. The signing process might make more sense in the context of plaintext http. And it might make the implementation of signed urls easier, idk. But, yeah definitely one of the rough points of the s3 api
3. An upload can just be a simple PUT in many cases. And for the cases where you do need a multipart upload: The Range header doesn't work the way you suggest, it is for requesting a range for the response, not giving a range for the data in the request. And even if you used a different custom header, you would need some way to indicate when you have uploaded everything. Maybe the API could be simplified a little bit, but I think quite a bit of it is essential complexity for the cases where you need multipart upload.
4. There are use cases where you want to use a different delimiter. And it's worth noting that as an object store, the data isn't really organized into folders, the / is just part of the object key. Definitely agree that it should support a JSON response though. And I do think it would make sense for / to be the default delimiter, because that is usually what people want.
> Basically I want to be able to use object storage with simple `fetch` and few lines of code. Without all that SDK nonsense.
If it weren't for 2, this would be possible. And that is a big reason why I wish the authentication was simpler.
All that said, I do wish there was a standardized specification for an object storage API, that all the different providers adhered to, rather than everyone making an "s3 compatible" API, where exactly what it means to be compatible with S3 varies from product to product.
- jsmith45 4y ago> The Range header doesn't work the way you suggest, it is for requesting a range for the response, not giving a range for the data in the request rfc9110 actually does permit servers to implement range on PUT, with partial update semantics, but warns that user agents can only safely do this if they know the origin server supports this, as if not the server could fallback to replacing the whole resource with just the uploaded range! (To my knowledge such support is not very common. Also due to risks of being misinterpreted by caches and other intermediaries, using the dedicated PATCH verb is probably better.) But this (ranged with PUT) is only semantically appropriate for updating an existing valid resource. For example, if you have database like file format, you can upload only the changed ranges which could be much much smaller than the whole file. Or for something like a log file, one could append new content to the end. For most files, breaking them into many parts for initial upload and range putting each part would be semantic inappropriate, since the resource is likely to only actually be valid once the last part is uploaded.