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..
