4 ms·
You're misreading the article. The problem has to do with uncoordinated breaking changes to a public API. There were no problems for our apps. Let me draw an a
by ocskills 18y ago
You're misreading the article. The problem has to do with uncoordinated breaking changes to a public API. There were no problems for our apps.
Let me draw an analogy: imagine that one day before release MySQL (or pick your favorite DB) decided to deprecate and ignore the the greater than > operator on queries. No errors - it would just pretend that query clause didn't exist and return all rows for queries that used a >. How would that affect your application?
The point is that when you expose a public API it becomes a contract with your developer community. If you make a breaking change to the API you have a fundamental responsibility to effectively communicate the change and ensure that it doesn't create massive and unpredictable results for clients. In this case Twitter didn't do either.
- jrockway 18y agoLet me draw an analogy: imagine that one day before release MySQL (or pick your favorite DB) decided to deprecate and ignore the the greater than > operator on queries. No errors - it would just pretend that query clause didn't exist and return all rows for queries that used a >. How would that affect your application? Well, most people would run their test suite, notice that MySQL broke, and then revert that MySQL update. Completely different. When you are accepting untrusted data from the Internet, you need to validate it. If Twitter sends you invalid data, it is your loss, not theirs. Code accordingly.
- jdminhbg 18y agoI got bitten by this as well, even though I'm checking for duplicates like you suggest -- it just jacked the total bandwidth usage way up, because calls previously returning 1 or 2 messages were suddenly returning the max every time.