> I think you aren't using the term API correctly.
I am. Public or private an API is an API. You seem to be under the impression that only a public API can be called an API which is nonsense.
> This discussion is about APIs for third party developers to write apps.
Which doesn't change the fact they have private APIs. My point was that they already have these APIs but they aren't public. They could be opened with minimal effort (compared to writing entirely new ones for PDS2).
> The fact that banks own mobile apps often use REST to communicate with their backend does not make such a protocol an API.
Of course it does, you know by definition[1].
> For one it's not documented, for another it may change without notice.
They are documented, but just like the APIs the documentation isn't public.
> Of course if you define "API" to mean literally any form of communication between processes or devices then sure. But then you'd have to consider GSM or FTP or TCP/IP itself to be APIs and I never saw them described that way.
No because I'm not an idiot. Those are protocols not APIs.
> My main point is that an interface that's just being driven by human interaction has very predictable load characteristics. If you open up a true API to third party developers they may come up with new uses that aren't directly human driven or may even be batch jobs. You don't have much control over your inbound workloads anymore.
Your case falls apart when you consider that there are already screen scraping services used by companies like Mint, Emma etc... these use way more resources than hitting an API and are already in use by hundreds of thousands of people.
1. https://en.wikipedia.org/wiki/Application_programming_interf...