All the banks I'm with use rest APIs in their apps (you can see this by MITMing the traffic), no "private protocol" whatever the hell that is.
As for controlling load, I'm not sure I follow. If you have 1m people with the mobile app installed and all of them decide to check their balance at the same time your systems are going to crumble if you've only provisioned for 10,000.
Web/Mobile banking doesn't talk to the mainframes directly, it's essentially a caching layer which gets committed later when the mainframe does it's job. Not much different from your average web app just with longer delays.
I think you aren't using the term API correctly. This discussion is about APIs for third party developers to write apps. The fact that banks own mobile apps often use REST to communicate with their backend does not make such a protocol an API. For one it's not documented, for another it may change without notice.
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.
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.
FTP TCP and IP are protocols, GSM is a european standard and REST is an easy method for building applications in which the backend is called the API (application programming interface) which typically use the http protocol. RESTful generally means using CRUD create, read, update and delete although it isn't a standard.
Some api's are private as in the one your bank's mobile app most likely uses. Some companies offer their API's to the public. They are both still APIs though.
> 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.
They can just provide them as-is, with no guarantees, and a big "things can and will break" disclaimer. This will be unusable for commercial usage, but will allow power users to automate their finances.
