The Api Paradox

I 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?

It 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)?

I 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?

I 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 still says "Api", not "API"?

In 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 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"