Hacker News Reader

Comment by profmonocle | Hacker News Reader

Treating a proprietary API as a standard is risky - this is a good example of why. From Amazon's point of view there's no reason to keep the S3 SDK backwards compatible with old versions of the S3 service, because they control the S3 service. Once this feature was rolled out in all regions, it was safe to update the SDK to expect it.

Amazon may not be actively hostile to using their SDK with third party services, but they never promised to support that use case.

(disclaimer: I work for AWS but not on the S3 team, I have no non-public knowledge of this and am speaking personally)

View on HN

This is the correct take IMHO. I generally dislike Amazon (and when it comes to things like the Kindle, I actively hate them for the harm they are doing), but I think this is the key. S3 is not and never has been advertised as an open standard. It's API was copied/implemented by a lot of other services, but keeping those working is not Amazon's responsibility. It's on the developer of a service using those competitors to ensure they are using a compatible client.

I do think some of the vendors did themselves an active disservice by encouraging use of the aws sdk in their documentation/examples, but again that's on the vendor, not on Amazon who is an unrelated third party in that arrangement.

I would guess that Amazon didn't have hostile intentions here, but truthfully their intentions are irrelevant as Amazon shouldn't be part of the equation. For example, if I use Backblaze, the business relationship here is between me and Backblaze. My choice to use the AWS SDK for that doesn't make Amazon part of it anymore than it would if I found some random chunk of code on github and used that instead.

Well, you do have to worry about customers using old client libraries / SDKs, even if your whole backend has migrated to a new API.

Many customers don't like to upgrade unless they need to. It can be significant toil for them. So, you do see some tail traffic in the wild that comes from SDKs released years ago. For a service as big as S3, I bet they get traffic from SDKs ever longer than that.

the server has to be compatible with old clients, but new clients don't have to be compatible with old servers, which is the case here

Ah, I see.

I think you've got the contract backwards. The server can't break old clients, but new clients can break the old server since Amazon controls the old server and can ensure that all of them are fully upgraded before the client updates are published.

Even more so: treating a proprietary API as a standard but _also_ adding your own checks on top which crash the interaction "because it seemed more correct to you". No, you are not guaranteed a CRC and you are not guaranteed a Content-MD5. Or - you may be getting them, but then do check whether they are in the signed headers of the request at least.

Reply on news.ycombinator.com