ReadWriteWeb

Alexia Tsotsis, who writes for TechCrunch, had this advice on Twitter earlier today: "Good tech blogger rule of thumb: Avoid using 'API' in headlines when/if you can." Usually, I'm all thumbs myself, but I can't find this particular rule on them anywhere. I suppose I'm not a blogger after all.

Or perhaps I just know my audience. The first rule of communication, as I have taught and been taught (both quite repeatedly, and often) is, "Know your audience." The API has become the principal communications tool of any company that does business digitally. Therefore, professes Netflix Director of Engineering Daniel Jacobson, when designing your API, you should identify, evaluate, and serve its audience just like with any other communications tool.

Several years ago, I spoke on a panel at an advertising industry conference with Om Malik and Michael Arrington. Arrington, my former employer, was bored by the conversation and mocked me throughout it. One of the last questions we were asked on the panel was what technology we were most excited about at the time. I said I was most excited by trends represented by a little startup called Rapportive, which sits in your Gmail sidebar and shows you aggregated information about whoever you are emailing.

Arrington laughed at me, just like he had laughed at me in the conference green room when I showed people photos on my phone of the chickens I was raising in my backyard. Just as I was vindicated when the TV show Portlandia later demonstrated that it is perfectly reasonable to raise chickens here in my home town, so too do I feel a little vindicated by the reported acquisition in the works of Rapportive by social network LinkedIn. OK, so both are a little silly. But the point is: Rapportive is awesome and I was right.

What we today call the "mobile app" could, in a very short period of time, become known as the portable app, or just the "app." It tends to use such a simple and straightforward model of interaction that people are starting to prefer using their smartphones for certain tasks, even when their PCs are right in front of them. By this time next year, portable apps originally designed for use on smartphones and tablets may be running on laptops.

The extent to which this changes everything is a topic that no one, not even ReadWriteWeb, has fully fathomed. The Web as we have come to know it will be affected significantly. What users have come to know as Web sites will be willingly and eagerly substituted with Web apps. In Part 2 of our interview with the co-author of APIs: A Strategy Guide, Netflix lead API engineer Daniel Jacobson tells us the one huge difference between an app and a site involves the extent to which they rely on an API. It is part of every app's DNA.

The first place I had ever seen an API actually at work was as part of an operating system. It was a strange OS at that, a permutation of CP/M that used a graphical front end called GEM, which would later be ported to the Atari ST. The definition was explained to me like this: An "interface," as everyone knows, is a specification for how electrical components interconnect. Well, now it's possible for an application program - the part that does what users need - to interconnect with the operating system, which does what the computer needs. This way the operating functions don't have to be built into every program, they can just be handed off to the OS and the connection will look seamless. The principle was called a layer of abstraction. It was 1984, and it was the first time I'd heard the term.

It would be wrong to call the concept "revolutionary," unless you measure time in units of eons. Nearly three decades after its introduction, only recently have businesses come to realize how widely this architectural principle could be applied. No longer do complex processes have to be bound to precise, policy-intrinsic procedures. If teams can work independently, and computer resources devised to suit each team individually, then all that needs to be specified is the exchange of information between them.

In perhaps one of the more counter-intuitive surveys to be published this year, commissioned by developer tools maker Apigee, a majority of businesses interviewed whose IT departments are currently managing API-intensive development projects say that integration with social networking sites is the least of their concerns.

Though the interview was limited to only 24 companies (leaving some doubt as to whether the sample size is adequate enough), the Web API study published by Hurwitz & Associates shows only 12% (3 firms) registering "expanding to social networking sites" as an important motivating factor for adopting APIs in applications.

Months after warning developers it would happen, the Google Developer team announced tonight that the era of unlimited Google Maps usage for free is officially over. Developers whose apps load more than 25,000 basic maps or 2500 stylized maps per day will have to cough up some cash.

An era has ended for the first API that really made mashups mainstream, most famously via housingmaps.com, a mashup of Craigslist rental search results and Google Maps. Unlimited access may no longer be available for free, but some observers say it's a good move for the developer ecosystem. "For some developers this can clearly be an issue but overall it's healthy for the ecosystem," John Musser of API watch-dog site Programmable Web told us tonight. "Services need to be sustainable with business models that work for both sides."

This Summer one of the world's biggest social networks, VOIP and chat service Skype, released an application developer platform for makers of electronic hardware to integrate features like Skype video calling into their gadgets. Today those same features were made available to developers of desktop applications and the new Skype App Directory was officially unveiled. There aren't a lot of apps in it yet - but there sure could be soon thanks to the new technical offerings for app developers.

Skype-powered apps have always been a source of huge unrealized potential. People say that your telephone contact list represents your real social network and the ultimate social graph to build apps on top of, but people do a whole lot of calling on Skype these days too. Add in video calling, screen sharing, text chat, file transfer and the P2P protocol it all runs on top of and what have you got? An awe inspiring opportunity. "Imagine the possibilities of Skype Video Calling directly in one or more of the desktop applications you use each and every day," the company says, "be it office productivity software or games."

Reid Hoffman, CEO of LinkedIn, told audiences today at the Web 2.0 Summit that the next stage of the Web will be building apps and mobile UIs on top of our collective data. Some people believe that a big part of that could come in the form of technology platforms that anyone can use to create those apps and UIs.

Cross-platform mobile Web apps may be poised to become a big part of the future of the Web, but they just aren't as powerful as native apps yet. Cabana, a do-it-yourself mobile Web app creation platform first seen at the Launch conference in February, announced a big new step today that will make mobile Web apps far more feature-rich as well. It's called the Cabana Exchange, and it's an API marketplace that allows app builders to incorporate some powerful 3rd party data and functionality.

Data marketplace and platform Infochimps launched a set of big new features this morning: a common geodata schema that aggregates information about places from multiple sources and offers it up in one API, an automated method of visualizing crowded geodata sets on a map called The Summarizer and a new method of allowing location data to be requested without knowing the latitude and longitude of a place.

If you look around where you find yourself in the world, physically, and are aware that there's really more to life than the naked human eye can see - the new Infochimps GeoAPI could be an important tool in shedding light on the quantifiable parts of reality previously hidden in a disconnected cloud of data.

Photo aggregation service Trove revealed results of a survey of Hacker News readers about API horrors and headaches.

Programmable Web (a site owned by ReadWriteWeb sponsor Alcatel-Lucent) counted up the mentions of specific APIs to try to determine which one drew the most ire from developers.

The verdict? Facebook is the worst. But actually, Facebook tied with "Other." Given that Facebook is one of the most popular APIs, can we really conclude that Facebook has the worst API, or just the most commonly used?