That's not true. Their API will now return the t.co URLs in the text section, so if developers don't do anything extra, things will (should, rather, I'm clarifying with them) still work, but t.co URLs will be displayed to users.
Their API will return the original links too with markers, so client code can be updated to display the original URLs. Twitter wants developers to display the original URLs and link to the t.co URLs.
Their rational behind this is flawed. One of the reason they are giving for implementing this is to be able to shut down links if they turn out to be malicious, possibly as a bait and switch. But since the right way to do a shortener is to do a 301 and that's what they say they are doing, they wouldn't have that ability.
Comments
That's not true. Their API will now return the t.co URLs in the text section, so if developers don't do anything extra, things will (should, rather, I'm clarifying with them) still work, but t.co URLs will be displayed to users.
Their API will return the original links too with markers, so client code can be updated to display the original URLs. Twitter wants developers to display the original URLs and link to the t.co URLs.
Their rational behind this is flawed. One of the reason they are giving for implementing this is to be able to shut down links if they turn out to be malicious, possibly as a bait and switch. But since the right way to do a shortener is to do a 301 and that's what they say they are doing, they wouldn't have that ability.
They could just stop giving 301s.
But 301 can be cached.
Can't you just set Cache-Control: no-cache to fix that?