5 ms·

If an open API existed yes there would be more integrations. Of course you would have to hire engineers to perform upkeep. Eventually if the ordering API isn't

If an open API existed yes there would be more integrations. Of course you would have to hire engineers to perform upkeep. Eventually if the ordering API isn't profitable you get a bunch of sunk costs and have to reassign people. Its not just "make this open" and POOF. Also your access could be revoked by unofficially using the API and or they could just change it at any time.

StavrosK 9y ago
It seems to me that you can make an API that is trivially reverse-engineerable and both have your pie and eat it.
- dave5104 9y ago
  In this case, don't you mean have your frappuccino and drink it?
  - karljtaylor 9y ago
    thanks a latte.
- tuna-piano 9y ago
  But then your users start using the Starbucks ordering Slack channel, cool! But their credit card is hacked. Or the slack channel breaks. Or a stalking ex-boyfriend intercepts the order and delivers the latte himself. Starbucks would likely be blamed for these problems. Remember the Snapchat leak from a few years ago?[1] I'd bet almost everyone who heard about the leak thought that Snapchat got hacked, and many then thought that their personal photos are not safe on Snapchat. But the reality is different. Users logged into a site called "Snapsave", many probably thinking it was part of Snapchat. It was Snapsave that used the private Snapchat API and got hacked... not Snapchat. [1] http://www.huffingtonpost.com/2014/10/10/snapchat-leak_n_5965590.html http://www.huffingtonpost.com/2014/10/10/snapchat-leak_n_596...
1690v 9y ago
It also expands the total attack surface of a system, which can lead to security problems. If you read some of the public disclosures from various bug bounty programs, neglected APIs have led to some serious vulnerabilities. "Underprotected APIs" is actually number 10 on the OWASP Top 10 for 2017.
- userbinator 9y ago
  The attack surface is the same whether the API is officially open/documented or not --- if you think that data received through a web API is somehow more trustworthy/less demanding of validation just because you haven't documented it and only release an app which uses it, you are doing it wrong. Conceptually, it's just a listening server on the public Internet, and will be subject to arbitrary data anyone willing to connect to it can send.
  - noway421 9y ago
    Published docs (auto generated or not) increase the risk of discovery. Security through obscurity, yeah, but it reduces chances.
shortstuffsushi 9y ago
Why would their API need to be anything more than what they offer to their app? Why not something like "hey, you can use our stuff, but you've only got access to the same set of APIs we use in our app, and we may change it as we please. Oh btw, here are the auto-gen'd docs, hope those are enough" That seems like it'd be both developer friendly and no more maintenance than they're already putting into it. The alternative is basically things like this, where someone figures it out anyway, and we have to wait and see if they play it cool, or take it badly and make the author take it down.
- BHSPitMonkey 9y ago
  You can't make breaking changes to a public API, for starters. Needing to maintain/version APIs you want to deprecate has a nonzero cost.
  - Spivak 9y ago
    Why not? The real cost would be documenting it, but a lot of devs would be willing to accept essentially being on a mailing list for breaking changes a few weeks in advance. It's not like Starbucks can roll out breaking changes to their own API instantly. It would only really be used by enthusiasts and techies who are used to this sort of thing.
  - TeMPOraL 9y ago
    Of course you can. All you have to do is to say: "this is our internal API, we're releasing endpoint documentation for curious developers, but be warned, that the API may, and will, change without any notice". I.e. when you're releasing something in the open, you don't have to take social responsibilities if you don't want to. It's not a binary choice between "release a fully supported product" and "don't release at all".
    - noway421 9y ago
      That makes me wonder, are the any commercial/consumer products that use that model?

StavrosK 9y ago

It seems to me that you can make an API that is trivially reverse-engineerable and both have your pie and eat it.

dave5104 9y ago
In this case, don't you mean have your frappuccino and drink it?
- karljtaylor 9y ago
  thanks a latte.
tuna-piano 9y ago
But then your users start using the Starbucks ordering Slack channel, cool! But their credit card is hacked. Or the slack channel breaks. Or a stalking ex-boyfriend intercepts the order and delivers the latte himself. Starbucks would likely be blamed for these problems. Remember the Snapchat leak from a few years ago?[1] I'd bet almost everyone who heard about the leak thought that Snapchat got hacked, and many then thought that their personal photos are not safe on Snapchat. But the reality is different. Users logged into a site called "Snapsave", many probably thinking it was part of Snapchat. It was Snapsave that used the private Snapchat API and got hacked... not Snapchat. [1] http://www.huffingtonpost.com/2014/10/10/snapchat-leak_n_5965590.html http://www.huffingtonpost.com/2014/10/10/snapchat-leak_n_596...

1690v 9y ago

It also expands the total attack surface of a system, which can lead to security problems. If you read some of the public disclosures from various bug bounty programs, neglected APIs have led to some serious vulnerabilities. "Underprotected APIs" is actually number 10 on the OWASP Top 10 for 2017.

userbinator 9y ago
The attack surface is the same whether the API is officially open/documented or not --- if you think that data received through a web API is somehow more trustworthy/less demanding of validation just because you haven't documented it and only release an app which uses it, you are doing it wrong. Conceptually, it's just a listening server on the public Internet, and will be subject to arbitrary data anyone willing to connect to it can send.
- noway421 9y ago
  Published docs (auto generated or not) increase the risk of discovery. Security through obscurity, yeah, but it reduces chances.

shortstuffsushi 9y ago

Why would their API need to be anything more than what they offer to their app? Why not something like "hey, you can use our stuff, but you've only got access to the same set of APIs we use in our app, and we may change it as we please. Oh btw, here are the auto-gen'd docs, hope those are enough" That seems like it'd be both developer friendly and no more maintenance than they're already putting into it. The alternative is basically things like this, where someone figures it out anyway, and we have to wait and see if they play it cool, or take it badly and make the author take it down.

BHSPitMonkey 9y ago
You can't make breaking changes to a public API, for starters. Needing to maintain/version APIs you want to deprecate has a nonzero cost.
- Spivak 9y ago
  Why not? The real cost would be documenting it, but a lot of devs would be willing to accept essentially being on a mailing list for breaking changes a few weeks in advance. It's not like Starbucks can roll out breaking changes to their own API instantly. It would only really be used by enthusiasts and techies who are used to this sort of thing.
- TeMPOraL 9y ago
  Of course you can. All you have to do is to say: "this is our internal API, we're releasing endpoint documentation for curious developers, but be warned, that the API may, and will, change without any notice". I.e. when you're releasing something in the open, you don't have to take social responsibilities if you don't want to. It's not a binary choice between "release a fully supported product" and "don't release at all".
  - noway421 9y ago
    That makes me wonder, are the any commercial/consumer products that use that model?