ReadWriteHack

Google opened its OAuth 2.0 playground to developers last November with support for Google properties and non-Google APIs with support for OAuth 2.0 draft 10. Since then, the company has added a number of new toys to the OAuth Playground, including support for testing client-side apps, in addition to testing Web-based applications.

In case you missed it the first time around, the OAuth Playground is a Google-sponsored site that allows developers to work with the OAuth 2 protocol.

If you are looking for large content repositories, you probably can't get much larger than the article archive of the Associated Press. Today they announced they have launched a content analysis tool that is used to search the millions of articles in their archives to create custom archive products for their customers. Users can query for particular keywords, and the AP can use the search query traffic to see trending topics and deliver article collections to particular B2B customers. For example, they could create references on a particular subject or moment in time. The project makes use of a solution from MarkLogic, a major Big Data enabler that is used by many different kinds of publishers for this type of purpose, such as Lexis/Nexis.

SendHub has put up a post on things its developers learned in rebuilding the front-end of its Web site as a single-page application with Backbone.js. This includes everything from template rendering to "avoiding a zombie apocalypse."

The company decided to give SendHub.com a facelift because "the site looked a bit dated, and it just didn't feel as snappy as we wanted it to. All pages were rendered almost entirely on the server, and only a couple of places used Ajax to pull in data asynchronously." The company also wanted to test out its developer API>.

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.

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.

Over the last year, a firm called Usergrid has been building an open source tool for leading mobile app developers through the process of creating back-end services for managing users. The Usergrid philosophy is contrary to quite a lot of the cloud-centered design methodology promoted by SaaS - the idea that the server can do everything, and a thin device can serve as the portal. Instead, Usergrid has promoted the idea of richer mobile apps that use Web services and APIs in a more passive, RESTful manner.

Late last year on its company blog, Usergrid stated its intent to build out to a cloud-delivered service - essentially, transferring its intelligence to the cloud to help devs build intelligence on client devices. This morning, the firm got its wish, though maybe in a way not everyone expected: Usergrid has been acquired by cloud-based API modeling tool provider Apigee. And as both companies' CEOs tell ReadWriteWeb, the fruit of their new relationship is a little ways down the road.

The picture recently painted of a network of ubiquitous connectivity for each and every class of processor-endowed device on the planet goes so far as to suggest that things such as shipping tags, pacemakers, pipeline stress sensors, thermometers, and nuclear radiation monitors expose their methods to the world - perhaps with a RESTful state. Only through such openness could the spark of ingenuity for a standardized, all-purpose API be generated.

As KORE Telematics President and COO Alex Brisbourne told us in Part 1 of this three-part discussion with ReadWriteWeb, the engineering of such specialized devices may actually work against the creation of such an API. But commonality and generalization of functions are what drive costs down for device manufacturers - the more specialized something is, the smaller its potential market. Is there anything that "intelligent device" managers could learn from the design of existing, specialized, narrowcast (to use Brisbourne's term) devices that developers may apply to the architecture of the devices that real-world apps will remotely monitor and manage?

Eric Bidelman, an engineer on Google's Chrome team, has released a JavaScript wrapper library for the HTML5 Filesystem API. Called filer.js, the library is available on GitHub under the Apache 2.0 License.

If Bidelman's name is familiar, it's because he wrote the book on the HTML5 Filesystem API, literally. Bidelman also worked on the Python Client Library for Google Docs.

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.