Hacker News Reader

Comment by laumars | Hacker News Reader

Is this really that out if character for Twitter as an organisation though? They have a history of being rather hostile toward developers and their own APIs. Which is ironic considering the nature of the platform.

I would say we should use this as a sign to migrate away but we've had enough warnings already. I guess Twitter is too big to fail?

View on HN

and this is yet another example why we need protocols and not APIs.

I treat the two as synonyms. What do they mean?

Perhaps "protocol" is meant as a standard specification (like ActivityPub) and "API" as a specific implementation for a company/service?

You could say that an API implements a protocol, but a protocol is much more general. For instance IRC is a well known and widely implemented protocol. Facebook messenger implements a protocol for client server commination, but there are few or none implementations if either side and the main implementation can change the protocol arbitrarily and without notice.

Right, but then wouldn't every API that has documentation also necessarily be a protocol (that might only be implemented by one provider?) If the idea is that you could switch to a different provider if you were using a protocol instead of an API, that only helps you if there is more than one provider of a protocol. In this case, someone else could take the public API docs and implement their own service that responds to the same API.

I would imagine the relationship similar to programming languages and standards; If there's no official standard, then usually for anyone trying to re-implement the language, they're "doing whatever the mainline version does". ie anyone trying to reimplement python does whatever cpython does, bugs and all, to claim "compatability".

But if a standard exists, that is, we've split the API from the primary implementation of the API, then we as a re-implementer no longer need to replicate bugs and all; we just need to do as the standard says, and anyone relying on cpython bugs is, well, at their own fault. Compatibility claims are no longer dependent on implementation-specific details.

And of course, it doesn't matter until a second implementation begins to appear; there's no reason for cpython to follow (or have) the standard unless it actually wishes to be compatible with jpython. At the same time, it makes a lot less sense for a second implementation to appear as well, as they have to put a lot of extra time and effort into matching cpython's implementation details (as far as they matter; a difficult determination itself), and this also makes it more difficult to produce an alternatively-optimized implementation (focusing on say, memory-usage instead of speed or whatever). So it's also a chicken and an egg problem.

So ideally everything would be an official standard, and we'd put little to no effort into simply matching whatever the popular implementation is at the moment, and we could criticize the mainline implementation for failing to adhere to the standard.

In this particular scenario, to replace smyte everywhere, transparently, you'd both have to adhere to the API and whatever details incidentally exposed by the API, because you have no protocol to actually reference (the protocol is whatever smyte was doing). But thats also particularly difficult here, since you can't even test it against an implementation of smyte anymore..

The term API has evolved to mean "a RESTful web service", almost always run by a company or organization. This surprised me on multiple occasions.

Kind of like how "cookie" is not web specific but unless mentioned in an explicitly nonweb context, it means browser cookies.

Reply on news.ycombinator.com