4 ms·

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 oft

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.

dsmithatx 8y ago
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.
deleted 8y ago
[deleted]
deadbunny 8y ago
> 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_interface https://en.wikipedia.org/wiki/Application_programming_interf...

dsmithatx 8y ago

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.

deleted 8y ago

[deleted]

deadbunny 8y ago

> 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_interface https://en.wikipedia.org/wiki/Application_programming_interf...