S3 is one of the original AWS services (SQS predates it), and has been around for 18 years.

The idea of a propriety API becoming the industry defacto standard isn't uncommon. The same thing happened with Microsoft's XMLHttpRequest.

Also, the S3 API is simple and makes sense, no need to reinvent something different just for the pleasure of it

There are valid reasons for extending and redoing some parts of the API. I will give you one example. Suppose you want to extend list objects to support ordering by last modified or you want to support filtering of objects by user metadata. Right now doing this is quite clunky via headers.

Supporting an existing API provides interoperability which is beneficial for the users. So that way if there is a better storage service it’s easier to adopt it. However, the S3 API compatibility can be a hindrance when you want to innovate and provide additional features and functionality. In our case, providing additional features [1] [2] while continuing to be S3 API compatible has forced us to rely on custom headers.

[1] https://www.tigrisdata.com/docs/objects/conditionals/ [2] https://www.tigrisdata.com/docs/objects/caching/#caching-on-...

Same thing seems to be happening with openai api

I might be misremembering this but I was under the impression that Ceph offered the same or very similar object storage API prior to Amazon building S3.

Because that's where most of the industry store their data.

Yeah I understand how it came to be, it’s just kind of an uncommon situation

Yeah--though I guess kudos to AWS for not being litigious about it.