The Google Plus API first opened on September 15, but the initial release was limited to basic public data. When Plus opened to all users on September 20, the API for hangouts - the video chat feature - was released as well. Now that search and the rest of the conversation features are available, Google Plus apps can get a little more interesting.

Today's API release makes available more of the features that make Google Plus compelling, and building apps on top of +1s and comments could turn the already chatty social network into a powerful tool for conversation.

Since Google put out a call for Plus developers, the API has been hotly anticipated, as we found in a ReadWriteHack poll this summer. But the releases have been slow and incremental, and the apps produced so far have been basic proofs of concept.

What kinds of apps would you like to see for Google Plus? Let us know in the comments.

Taking the top prize is a handy little Web app called Plan My Next Trip, which uses your Foursquare history to recommend things to do when you visit other cities.

With Plan My Next Trip, all I need to do is authenticate my Foursquare account and then enter the name of the city or town I'm heading to. It will take my friendships and past check-ins into account and spit out a two-day itinerary for me. If friends of mine have been there, it will let me know. If they've left tips, I can read them. Venues that are currently popular on Foursquare will be noted as such.

The project comes from Benjamin Netter, a Web developer based in Paris. The day-to-day itinerary it builds starts with an ideal spot to get breakfast and then continues on to other venues throughout the day and evening, Netter told us. The schedule includes a mix of venue types, like food, drink, arts and public parks and tries to build a list of places to go that are relatively close together.

When I do a search for Washington, D.C., one of the recommendations is Chinatown Coffee Company. Foursquare knows I check into a coffee shop almost everyday. It also knows that my friend Jeff has checked into that cafe five times and my friend Daniel checked in once as well. Those guys don't even know each other.

The results can be a little mixed sometimes. As part of my theoretical trip to D.C., it recommends that I stop at Safeway. Depending on the scope and purpose of my trip, I may not need to go to a grocery store. It's okay, though, because at 10pm, Plan My Next Trip tells me to go "get drunk" at The Passenger, a popular bar that Jeff and Daniel have both been to several times. Sounds like a plan.

The app itself is not very useful yet, but it's a start. "Some categories are not meaningful," Mansour says, "and I am trying to optimize it further which is quite difficult." But Mansour's insights after developing for the API are instructive. On the Stream+ website, he says that the API was "very easy" to learn and use, but that it suffers from "extreme slowness" in practice.

"So far, the API looks solid," Mansour says, noting that he built Stream+ without prior knowledge of AppEngine or OAuth. "Props to the AppEngine team, you guys really did something so easy. ... I just used the examples online given by the Google+ team and hacked away with the API. I am really impressed."

Mansour is a committer to Chromium and a Google Qualified Developer for Chrome Extensions, and his experience developing for the Google Plus API seems to parallel that of using the social network. It may not be capable of much yet, but it delivers simply and effectively on the features that have been released.

He did note, however, that the API is not very responsive. "It takes 30+ seconds to query the public stream (not many posts) and another 5+ seconds to classify them in memory!", Mansour says.

Proof of Concept

As far as the Stream+ app itself, I'd have to agree with Mansour. "Some categories are not meaningful." In fact, not very many of them are. The app does take quite a long time to load, and when it does, it presents an overwhelming list of past threads and an inscrutable list of topics. Examples of weird topics in my list are "Think this New," "Hear," "Long Time" and "Little," but others, like "Social Media" and "Web News," make more sense.

But keep in mind that this is not Mansour's forté as a developer. In fact, Stream+ at least tries to solve a crucial problem with Google Plus: organizing the stream. The Google Plus stream is currently this avalanche of multimedia madness, and drilling down by circles doesn't really help make sense of it. At least for public posts, an application like Stream+ could impose some topical order on it. (Side note: Where is Sparks? Isn't this what Sparks is supposed to do?)

Mansour has opened the future of Stream+ to discussion on Google Plus, noting that "it will always remain free," and that he hopes to open-source the technology.

Just The Beginning

Mansour has at least proven that something can be built on the Google Plus API as it exists right now. Even if the app isn't very helpful for end users, Mansour found the process of developing for Plus relatively easy. The long response time is a shame, but the Google Plus team is working to make this API easy and useful.

When Google announced last week that it was opening the first part of the Google Plus API, the public response was lukewarm. The release only gave developers access to public data; any info that is less than totally public, including circles, is still unavailable. Management of circles is one of the most painful parts of using Google Plus, and developers would love to get their hands on it. But alas, that will have to wait for a future release.

What kinds of Google Plus apps do you want to see? Let us know in the comments.

The time has come for outside applications built on the Google Plus platform. With this release, Google has laid out its policies for independent developers, which it summarizes with three simple principles: "put the user first, be transparent, and respect user data." And with that, off to the races.

The Plus team also makes an effort to adhere to open Web standards. "We love the way the programmable web has evolved," the post says, "so we're using existing standards and best practices wherever we can." This is a refreshing message, considering the attention Google has attracted recently for seeming to work against Web-standard technologies and practices.

Since the social network launched in June and put out a call for developers, this API has been hotly anticipated. Our ReadWriteHack poll found that a commanding majority of our developer readers were interested in playing with it. This summer, we laid out some ground rules about what Google would have to do to win developers' hearts with this API, and it looks good so far, though devs only have access to public data at this point.

More Google Plus API news is sure to come following this first announcement, so stay tuned.

What kinds of apps would you like to see built on top of Google Plus? Discuss in the comments.

Select developers have had access to the API since the company's last hackathon and have been using it to build applications that take advantage of the Foursquare's push notifications. The API will go into a public beta just a few days before the company's global hackathon on Saturday.

A more specific example would be 4sqtransit, a service that sends up-to-date public transit schedule information to people when they check into a transit stop. It works by pairing a Foursquare user's check-in with data about transit stops and schedules from another database. Depending on their location, it sends a text message to the user containing the next few departure times.

4sqtransit creator Matt McCormick explains in further detail:

When a user checks in on Foursquare, I receive a notification from the Foursquare Push API that the user has checked in, with details about which of my users checked in and where they checked in at. My service then matches this Foursquare user to the user in my database to determine which transit agency they use, which they specified when they signed up for my application. I then query that transit agency for the nearest transit stop, based on the GPS coordinates of the user's check in location from Foursquare, and calculate the distance from the user to the transit stop. If the stop is within 100 meters of the user's check in location, then I move forward and deliver the stop times, otherwise I ignore the check in. To deliver stop times, I again query the user's transit agency for the stop times in the next 2 hours and send this information to the user by text message, using Twilio.

Pretty neat. It should be interesting to see how this API is used once it's available to a wider group of developers. For samples and documentation, check out its listing on Github.

"We know Americans want the kind of immediate access to government that the Internet can provide - they're connecting with Congress on Facebook, asking President Obama questions over Twitter and can now bring Washington right into their living room using our new Sunlight Roku apps," said Gabriela Schneider, Sunlight's communications director. "We hope to prove to all branches of the federal government that they should make their work available in open formats, because Americans are, indeed, interested in knowing and engaging more with their government."

Word of Mouth

In the weeks since their release, the apps have been downloaded thousands of times without any promotion, suggesting that there is real interest in tracking the events in Washington among the owners of the one million Roku boxes that have been sold to date.

According to the Sunlight Foundation, at last count the White House app is the most popular, with downloads to 6,489 accounts. The Congress app is on 2,800 accounts and the Supreme Court app on 3,016 accounts. The White House app is built around the video and text feeds from WhiteHouse.gov. The congressional app pulls from Sunlight's own real-time API, which any developer can do if they wish. (The code for all of Sunlight's APIs can be found at the Sunlight Labs github page.) The Supreme Court app is limited to audio, due to the prohibition on video recording in the highest court in the land, which it pulls from the Oyez Project.

The release of these apps follows the considerable success of the Sunlight Foundation in releasing apps that help make government more transparent. The Real-Time Congress iPhone app has now been downloaded 24,469 times, according to Sunlight.

The open source Android version of the Congress app, however, has proven to be much more popular, with over 400,000 downloads to date since its release and between 60,000 and 80,000 uses a week, based on the API calls its users have been making.

Open government? There's an app - and an API - for that

The use of these apps, as a whole, highlights both an evolution of open government advocacy and an important trend for non-profits in general to internalize: in 2011, making more open data available using APIs, embeddable media and applications for mobile platforms or appliances enables an organization to reach far beyond a single website. White House and General Service Agency (GSA) officials in charge of the federal .gov review process appear to have internalized the same message, which will be important as the GSA moves forward with its Mobile Gov initiative.

While Washington tends to lag behind the private sector when it comes to technology, some pockets of innovation have emerged. As Steven VanRoekel, the new federal chief information officer, begins his first full week on the job Monday, it's worth noting that during his time at the FCC, he said, "everything should be an API."

If VanRoekel can include moving forward on that vision for open data in the context of his priorities, which include cybersecurity, moving to cloud computing and mobile government, citizens will see more apps that spur better decisions and new businesses.

The Sunlight Foundation's own Sunlight Health app already demonstrates one possible direction. Imagine if liberated financial data were to be baked into more apps in the future.

But as the list of Google's APIs continues to grow, there are some older APIs that are, in Google's own words, no longer "receiving the necessary love."

Those APIs that will be shut down include the Blog Search API, Books Data API, Books Javascript API, Image Search API, News Search API, Patent Search API, Safe Browsing API (v1 only), Translate API, Transliterate API, Video Search API, and Virtual Keyboard API.

Google says that it closely monitors the usage of its APIs as well as the resources necessary to support them. In some of the cases, those APIs that have been targeted for deprecation or shutdown weren't being utilized or the projects they were related to have been shuttered - such is the case with the API for the ill-fated Google Wave. But in other cases, newer APIs have replaced them - that's the case with the book-related APIs that are slated for closure.

Google says that it will suggest alternatives to developers so that they can achieve similar functionality - whether it's pointing to a new version or to a related one. It also says that it has lengthy deprecation periods - as long as 3 years in some cases - in order to help minimize the impact.

When users authorize to a third-party app for the first time, they'll see a new permissions screen detailing what that integration with Twitter means. This can include activities like reading tweets, seeing who the user follows, tweeting on a user's behalf, or accessing Direct Messages.

Then at the end of the month, those apps that needn't access DMs will no longer be able to do so.

An Oft-Requested Change

According to Twitter, this change has been something both users and developers have long been asking for. But until now, developers have not had granular control over the content they could access, unlike for example apps on the Facebook platform. With Twitter, it's been all or nothing. Users have had to hand over the keys to all these activities when authorizing a new app, something that might make them uncomfortable when just trying out a new service.

Tim Haines, founder of Favstar.fm which allows users to keep track of Favorited messages, says that "As an app developer, I'm happy for this change." Favstar doesn't need DM access, so he's happy to opt out. He hopes that by being able to assure users that the app doesn't access their private messages, that more users will be likely to sign up.

New Permissions for Apps that Access Direct Messages

But now there is a new permission level called "Read, Write, & Direct Messages," according to Twitter Developer Advocate Matt Harris. If an app does require access to this permission, developers will have to make some changes and will have to use OAuth, not xAuth. "To ensure users know that an application is receiving access to their direct messages," says Harris, "we are also restricting this permission to the OAuth /authorize web flow only."

This change might put some pressure on developers of iPhone apps that will have to hustle to update and resubmit for review. The change might also make the user experience on mobile apps a little more awkward as users will be prompted through the webflow that xAuth currently avoids (and by extension, this might make Twitter's own mobile apps seem much more slick).

Applications that don't need to read direct messages won't need to make any changes, and users of these apps won't notice anything different when these permission levels change.

Lee calls the current patent trolling, where firms such as Lodsys and others are threatening to sue developers who don't license patents for technology developments like in-app purchasing buttons and the use of forms, an "untenable situation" for developers. "There is no move we can make that will result in our ultimate survival. Either we pay Lodsys and usher in a new era of extortion, or we refuse to pay and are sued out of business."

But there's a third option, he offers. Developers can put pressure on Apple by boycotting the use of any API that comes under fire from these patent holders.

An API, or application programming interface, is a tool used by application developers to facilitate interactions between different software programs. For example, the case of the Lodsys patent claims, developers who have implemented Apple's in-app purchase API, which allows an app's users to pay for goods or services within the app itself, have been targeted for including an in-app "upgrade" button within their applications.

Although Apple has licensed Lodsys' patents, the firm claims that the license does not extend to the wider community of third-party application developers.

Also this week, a second patent-holding firm called MacroSolve has been outed as suing nearly a dozen developers on both Apple's and Google's Android mobile platforms for using forms within their apps.

For indie developers, the situation leaves them feeling helpless. As Lee explains, "if we pay, we are collaborators in our own demise, as the precedent this sets will open a floodgate of parasites extorting licensing fees for their alleged patents, knowing we are too weak and too scared to do anything but pay. If we don’t pay, we’ll still be out of business, just quicker, as we are sued out of existence."

Although Lee is not currently developing iOS applications, he now works for a company called Sofa, a maker of Mac apps. Sofa is not affected by this issue directly, but it is affected by the precedent being set, as are all developers, says Lee.

What Can Be Done?

Lee is suggesting a boycott of Apple's in-app API, as well as any other API "that is infected by parasites," as he describes it. He does not say this because he has no faith in Apple, but because Apple has "infinite time" to address the situation and are "typically conservative in their response." Lee thinks developers need to light a fire under Apple, to urge them to move quickly.

In a blog post, Lee details precisely how developers can participate in such a boycott. Within an application, a developer can add an alert which would appear anytime a user attempted to make an in-app purchase. The alert would read something like this:

We are unable to support in-app purchase at this time due to the threat of lawsuit.

more information

In addition, Lee says developers can file a bug that duplicates bug #9459079, which reads:

Summary:

Use of the system-provided In-App Purchase API opens developers to patent infringement lawsuits from patent troll Lodsys, who are demanding licensing fees above and beyond Apple’s 30% cut.

Steps to Reproduce:

1. Ship an app that uses the In-App Purchase API

2. Wait to be contacted by Lodsys

3a. Pay Lodsys, and every patent troll that inevitably follows them

3b. Be sued out of existence

Expected Results:

Apple steps in using their nearly infinite financial and legal resources to protect their developer ecosystem, removing the threat of Lodsys, and ultimately pushing for reform of our broken patent system.

Actual Results:

Apple remains quiet, while their developer community privately and publicly freaks out.

Regression:

Dozens of developers, including James Thomson and Apple Design Award winner Iconfactory, have already been targeted by Lodsys.

Notes:

Some reassurance from Apple would be nice.

Developer Response So Far

Such a radical and aggressive action may be feared by many iOS developers, who have typically been careful to not anger Apple in any way, and have tried to always follow the company's strict rules regarding application development practices.

Lee admits that, while overall, the response to his suggestion has been "overwhelming positive," there has also been some negative reactions, too.

"People are terrified," he explains. "Some people want to lawyer up, without thinking about how expensive that is. Others want to pretend it doesn't exist, or that it's not an issue. You can expect all the standard Kübler-Ross reactions: denial, anger, bargaining, depression, and acceptance."

But Lee believes a boycott may be the only way for developers to really have an impact. Feature adoption and bug reports are metrics which Apple is known to value, he says.

A small handful of developers have agreed to participate in the boycott so far, and are tweeting their support using the new #unlodsys hashtag on Twitter. Lee suspects that many more will simply pull the API quietly or file bug reports.

I don't know about you, but when I hear the word "Lollapalooza," I think about beer, grunge rock and application programming interfaces. Wait, what?

Okay, so maybe an API isn't exactly what comes to mind, but this year, the rock festival that once helped propel bands like the Red Hot Chili Peppers and Pearl Jam is looking to launch something else entirely: an open API chock-full of real-time scheduling data, stage geolocation and more.

Lollapalooza is offering over $5,000 worth of prizes and tons of promotional exposure for the best mobile, web and desktop apps created using their API. Developers can access data on artists, events, stages/venues and updates for Lollapalooza 2011. Prizes will be awarded for apps that help fans get the most from their Lollapalooza experience before, during and after the Festival. Winners will be promoted on the official Lollapalooza website and to fans via email, Facebook, Twitter, and the jumbotron screens at the Festival.

The HackLolla website has the full list of rules and deadlines.

If music and hacking are your thing (and let's face it - you're here, so they are) then you might also want to check out this weekend's San Francisco Music Hackday, which is being sponsored by Lollapalooza. The company will be making a more in-depth announcement on HackLolla. Immediately following, San Francisco will be home of the SF Music Tech Summit.

In all, it's a good time to be a music-loving hacker.

Last month at SXSW, Infochimps, the self-described "Amazon of data," unveiled thousands of new API calls. The API calls, or plug-and-play bits of code that developers can insert into their applications, were released in hopes of soothing the headaches inherent in making data-dependent applications.

This weekend, a few developers took three headache-free days to make three awesome Twitter apps built on the Infochimps API calls.

Check 'em out.

If you search on Twitter, the results you get come from what a person says in their tweets. It doesn't search their bio. Plum.ly allows users to keyword search across anyone's Twitter bio and returns results according to TrstRnk, the Infochimps' Twitter-influence score. It lets users search not only the bio, but also the name and location. For example, if, like me, you wonder who else made the reverse migration, you can look for "Austinite in San Francisco." It even allows users to quickly look at these results and see who these people are communication with on Twitter and look at the conversations they're having.

Steve Odom put it together using the Strong Links, TrstRank, Conversations, and Qwerly API calls.

TweetDegree - follow the right people

Say you meet someone involved with the Android developer community and you want to meet more people like them. How would you go about that? One way would probably be to look at the people they talk to and communicate with most, right? TweetDegree does just that. It helps you to quickly find the people they follow and Interact with on Twitter. Just enter a name, and it shows the various levels of interaction from there.

It uses the Infochimps Strong Links and TrstRank API calls and was built by Taecho group.

TweepleFight - measure Twitter topics in microBeibers

Everyone loves a good fight, right? Infochimps' own CTO, Flip Kromer, built this Twitter-based battle that allows users to compare the relative frequencies of words or phrases using Infochimps' Twitter People Search API. Far more interesting, though, is how it makes these measurements - in "microBeibers." What in the world is a microBeiber?

*µBb (microBiebers) -- Each microBieber corresponds to one-millionth the popularity of Justin Bieber in user profiles. For example, about 10,000 users mention "bowling"; as a fraction of the 200,000 who mention "Bieber", that's 5.3%, or 53,000 µBb.

I guess we can't take down the king himself.

For more about the Infochimps' API calls, read Sarah Perez's full write-up from SXSW.

Anyone can visit the Europeana website to search through the materials. And now, thanks to its newly released API, other applications and services may soon be on the way.

The Europeana Hackathon Projects

The Hackathon earlier this month was by invitation only, and currently European's API is only available to its partner developers. Those restrictions stem, in part, from the agreements that Europeana has had to make with institutions in order to access, search, and display their digitized collections.

Nonetheless, those who did participate in the Hackathon did build some great tools, including at least one that Product Developer David Haskiya says that Europeana will use itself.

One project was component built for the open-source content management system Joomla that includes both a keyword search and a map search. With the latter, you can look up objects in the the Europeana database within a region.

Another project built a wrapper for the Europeana API, helping geo-enable the queries. Then, by interfacing with OpenLayers, you can draw a box on a map, setting a boundary for your search, which will plot the results on a map. (You can view the demo here.)

And just so you don't restrict your searches solely to the most famous of Europe's cultural artifacts, one project will help with discovery: a random image explorer.

Why Digital Libraries, APIs, and Hackathons Matter

The debates surrounding the importance of and the obstacles to any sort of national digital library have certainly resurfaced following the recent Google Books decision. Who owns the rights to cultural artifacts? Who can and should be responsible for digitizing these artifacts? Who then stores them? Who can access them, and how?

These debates, of course, aren't new - in the U.S. or in Europe. In January, a European Union report cautioned its member states against turning over this efforts entirely to the private sector.

While these contentious legal issues are still being worked out, the Europeana API - and the hackathon - point to another important aspect of these sorts of projects. A digital library isn't simply about the preservation of important cultural material. It's about making sure that material is accessible. And with an active support for linked data and now with an API, it looks like Europeana is well on its way to moving these sorts of efforts forward.

Image credits: Ton Zijlstra

Until now, there has been no quick and simple way to embed a functional Tweet in a blog post. That is, most of us bloggers simply took a quick screenshot, uploaded the image and used that, meaning that users were left looking at the picture of functionality without any of the benefits - they couldn't follow, retweet, reply or favorite a thing.

Today, Twitter has released a new set of developer tools that will make it easier for bloggers and others alike to embed fully-functional Tweets on the Web, with WordPress leading the pack.

Twitter had previously offered a way to embed Tweets with a feature called Blackbird Pie, but the resulting embed was lifeless. Users couldn't interact with it in any way. The new feature allows users to interact with the embedded Tweet as if they were on Twitter's website itself, even offering a mini-profile feature, similar to the Hovercard.

Already, WordPress has offered an updated tool, writing that "Twitter Blackbird Pie Just Got Even Sweeter." For WordPress users, the change will be immediate and automatic - all Tweets on Wordpress.com blogs will display in the new format.

For the rest of us, however, there is a little simple hacking required, though the how-to is fully detailed. We'd be surprised if a tool for doing this quickly and easily weren't out and free on the Web by the end of the day.

Now, this isn't to say that you shouldn't go getting that screenshot while you're at it. The new feature works by referring to the Tweet by ID, which means that if the original poster deletes that Tweet, your embed will have nothing to show.

Update: A Twitter spokesperson offered a clarification on this story, saying that "we have not released a way to embed Tweets on websites. We released a new API (Web Intents) that makes it possible to add interactive Reply, Retweet, and Favorite links to tools and widgets that display Tweets on the web. The first partner that implemented the API was Wordpress with their Tweet Embed/Quote tool."

In the past few years, we've seen the emergence of the application programming interface, or API. APIs have become very popular. It's evident when you look at the directory from Programmable Web, which has 3,000 APIs.

APIs are used all the time to connect Web apps, cloud-based services, devices and increasingly, inanimate objects. APIs are making our world programmable. We can program a bridge, the door to a house or the cart that trucks your luggage to the plane.

And with mobile devices, we can track that data no matter where we are and use real-time analytics and a geospatial context to find intelligence in the collective data.

The Internet of Things is only practical when you have a critical mass of devices and a cloud infrastructure. We have that now. But we also need the geospatial context to know where everything is located, all the time.

All of this has implications on the way we work.

For example, a municipality cannot afford to replace all of its aging roads and bridges at one time. But it can place sensors to transmit data that can then be analyzed in real-time. The analysis tells the people managing the system how the bridge is faring. This can be replicated across the entire transportation network.

By doing that, the systems manager can get a granular view that was not possible before. Road crews with sensors on trucks can be monitored, too. Teams can be distributed across the network, based upon the data analytics that indicate weak points and potential weak points in the system.

This kind of approach means automation on a scale that we have not seen before. We need this automation as this kind of data becomes a deeply woven mesh into all aspects of society.

Photo by gerard79

I'm not sure that the future of marginalia is quite so dim. Nor do the folks at ReadSocial, who are working on an API that would, as the name suggests, help open up our digital annotations to others and help make e-reading social.

ReadSocial's API aims to provide a social layer that works on top of and across reading systems. In other words, it means that passages from books, magazines, newspapers, blogs, and so on can be excerpted, annotated, and pushed to our social networks. The API would serve to free content and discussions from being siloed in a single platform

Making Notes in the Margins of the Google Books Library

ReadSocial has developed a proof-of-concept project that uses Google Books and Facebook to demonstrate how this can work. It's called Readum, a Firefox and Chrome extension that lets you highlight any passage from a Google Book, attach a note, and then share it to Facebook - to your wall or to a Facebook group.

Close Reading 2.0

My background in literature, I'll admit, makes me pretty excited about the prospects of this API, and the founders of ReadSocial - Aaron Miller and Travis Alber - share that literary background too. The two are also the co-founders of BookGlutton, and the idea for the ReadSocial API stems in part from their work there, making online reading more social.

Of course, thanks to Web 2.0, much of the reading that we do online has become social, in some way or another. We can share links to articles. We can leave comments. But those comments come at the end of an article or blog post, which arguably means you get quite a different sort of response than you would if you could offer your thoughts in the margins throughout.

Being able to read a text closely, point to a key place in an argument, and offer your insights is one of the cornerstones of literary criticism, and it's the motivation in many ways for marginalia. The ReadSocial API has great potential to bring this longstanding tradition of close reading online.