6 ms·
The Api Paradox
- brazzy 14y agoCan we please, pretty please with a cherry on top invent a new word for "public-facing official API that exposes some of a company's core services"? Because I get annoyed every time someone uses "APIs" to make general statements while assuming that specific narrow meaning.
- johns 14y agoI think that ship has sailed.
- wallflower 14y agoI always liked the term 'Business Objects' - but that has always been co-opted by a company (SAP). So hard to invent catchy new terms... Trying here but they all sound like business buzzwords... Business Proxy, Business Delegate, Business Front, Business Agent, Company Blackbox, Business Interface, Company Platform, Company Rube Goldberg, Company Socket, Partner Interface?
- tod222 14y agoOkay, how about SPI, Service Programming Interface?
- brazzy 14y agoI'd be happy with that. Now to get people to use it...
- kiriappeee 14y agoPAPI?
- richardjordan 14y agoThe key is I distinguish between an API which IS the business - something like a Twilio for example - and an API which lets you leverage a business's other assets in a way that might one day be cut off - like a Twitter. You are safe to build on top of something like Twilio because the service is the API and API consumers are the customers. Consumers of Twitter's API are not customers of Twitter and should not be surprised Teotter does not treat them as such. You are either the customer or the product. If you are neither you are in a precarious position.
- bravura 14y agoI appreciate your distinction. This in fact is one of the red-flags he suggests: "[Be leery if] the API offers no (or very little) prospect for being monetized in the future"
- pc86 14y agoI think you're still in a precarious position as the product. Just look at Facebook, Google et. al.
- etfb 14y agos/Api\'s/APIs/g s/Api/API/g I know it's nitpicky, but the error makes it painful to read the article. Obviously I'm blaming nobody, and to judge from his name the author is probably fluent in more languages than me. But it's a user-friendliness thing. It would help.
- jacquesm 14y agoThanks, I'll fix those. Ok, fixed. Have an upvote :) & thanks again!
- asmosoinio 14y agoI think you may have broken something while doing this? I see this on your main page: --- The Api Paradox APR 11TH, 2013 – layout: post title: The API Paradox date: 2013-04-11 11:00 comments: true categories: api development startups programming permalink: /api-paradox --- And the page at http://jacquesmattheij.com/api-paradox http://jacquesmattheij.com/api-paradox still says "Api", not "API"?
- jacquesm 14y agoA case of a misplaced dash in a markdown file... Fixing, regenerating, deploying. eta 10 minutes, thank you very much!
- etfb 14y agoNo, YOU have an upvote! Thanks!
- entropy_ 14y agoEnglish is my third language(after Arabic and French) and that was still annoying to me. I know it's a nitpick, but I can't help being bothered by misplaced apostrophes. Props to the author for fixing it so quickly.
- johns 14y agoI don't think the age of the company matters much. Incentives can be aligned/misaligned at any age. I wrote a similar post not that long ago that argues many of the same points (albeit with a more incendiary title) http://thenextweb.com/dd/2013/03/12/apis-are-dead-long-live-apis/ http://thenextweb.com/dd/2013/03/12/apis-are-dead-long-live-...
- pjmlp 14y agoWhen are we going to stop calling API to web services? It always comes to my mind operating system API when I read such titles.
- jacquesm 14y agoIt seems to be the accepted use these days. I disagree with that use but I don't have a better term and don't want to add to the confusion. But you're absolutely right that an exposed service and an API are different in many fundamental respects. I think the confusion is rooted in the gray area called remote procedure calls, if you implement your service exposure as a remote procedure call (and many of the early ones were done in just that fashion) then the difference is almost moot. Maybe WSI would be a better moniker? (Web Service Interface)?
- j4_james 14y agoI always thought "protocol" was a more appropriate term for such internet-based APIs. SMTP and HTTP are clearly protocols, and even APIs built on top of HTTP are generally referred to as protocols in the standards world. For example WebDAV (RFC4918) and AtomPub (RFC5023) are both considered protocols.
- thebuccaneer 14y agothis begs for a 'no s--t sherlock' comment
- SPSteinbeck 14y agoAnd your response begs for a downvote.
- thebuccaneer 14y agowhy? for pointing out that, in 2013, someone had the revelation that if you fish in someone elses pond, be careful... because they might cut off your access?
- rolfvandekrol 14y agoI don't see why "It is possible to create a competing business using that very same Api" is a potential warning sign. Anyone got some thoughts about that?
- thebuccaneer 14y agotwitter
- netcan 14y agoBecasue if they want to kill that competitor & take over their business, they can just cut them off from the api.
- asmosoinio 14y agoGreat article! typo: "If you do not heed that than chances..." than => then
- jacquesm 14y agoFixed, thank you!
- DanielBMarkham 14y agoIn startups, we often tell each other that "the idea is useless", that is, startups are not about the technical details of the idea, they're about the human-to-human interaction of people and your business. This is also true about data. Startups are not about the data. A dozen companies did what Dropbox did, but there was only one Dropbox. Everybody did search, but there is only one Google, and so forth. Yes, people consume the data, and yes, if you ask them they'll say that's why they're using your app, but that's confirmation bias. They already use your app and enjoy it. When you ask them, they just look at what the app does and repeat it in a way that makes them sound the smartest. So, presto chango, adding those two things together along with Jacques' essay and we end up in a really weird spot: your startup may be about providing some kind of massaged data to end users. So you find an API to do that. But the guys providing the data, the heart of your app, have the least amount of reward in the entire equation! Hell, in many cases they're providing data willy-nilly out to just about everybody for free. To them, the data is worthless, yet you're building your business off them! Crazy world. I have a personal news aggregator I wrote a couple of years ago, http://newspaper23.com http://newspaper23.com Nothing fancy, just rips some headlines, then rips the plain text, then puts the plain text in json and makes a client-based detached reader. To provide the plaintext, I was using ViewText. Great folks. Put in an URL and it'll give you a readable version of what's there. But guess what? The ViewText guys didn't like my app ripping 50-60 articles a day. So I lost this huge amount of functionality when they decided to start rate-limiting. Now when you click an article, I bring up a frame and load it. I wanted plain text, this was the entire reason for the app, and now the critical thing I wanted is the exact thing that isn't working. No big deal for my newspaper23 app, but it would be a freaking red alert if this was something I was selling. API use, like walled gardens, are high-risk. EDIT: Fixed possessive version of "Jacques"
- jacques_chester 14y ago> ... along with Jacques essay ... Tiny, irrelevant nitpick. Assuming that Jacques Mattheij is using the French pronounciation of his first name, the possessive version of Jacques is Jacques's. This is because in French the final letter of most words is silent, and in English the possessive form of spoken nouns not ending in an audible "s" is rendered in text as <singular>'s. Phoenetically: zhahk -> zhahks Not: zhahks -> zhahks. Regards, another Jacques.
- milliams 14y agoFor some reason it really annoyed me that he was spelling it "Api" rather than "API".
- deleted 14y ago[deleted]
- websitescenes 14y agoGreat writeup. Agree with everything that was said. I am currently building a service with much of the functionality based upon an API. The concerns the author has mirror my own. Perhaps there should be an API code of ethics; somewhat like open source licensing. Not one for regulation but it would be nice to have some assurances for both parties involved.