Tagged: api

rules.io introduces open source API framework: Geekier

reblogged from The last gem you’ll ever need? – thisblog.rules.io.

The Last Gem You’ll Ever Need?

David Anderson — Dec 6th, 2012 —

At rules.io we have benefited from many open source projects, such as Ruby on Rails, D3, and Ember. Now we want to start giving back, with a project called Geekier.

Background: so many APIs, so many gems

It is increasingly the case that building any sort of application, be it for the web, or mobile, or desktop, means connecting to several online services via APIs. As a developer, I mostly view this as a good thing, because it means I can offload all sorts of things that I care about doing well but that aren’t central to how I provide my unique value. I want things like payment handling, exception reporting, and analytics, but I don’t want to build them all myself.

As a frequent consumer of APIs, I’ve looked at lots of API specs and libraries over the years. If you are an API provider, and you’re thinking about writing a client library (or ruby gem, or python egg, or …) then I have one piece of advice for you: don’t do it.

Read the rest at The last gem you’ll ever need? – thisblog.rules.io.

Advertisements

USA Today Latest Media Co. to Realize Open is Better «

USA Today is the latest media company to open up its data via an API, the software interface that makes it easy for outside developers to use another company’s data in their applications. The newspaper — which said that it will launch its open API project later this month — joins a small but growing group that includes The Guardian, the New York Times and National Public Radio. The newspaper says it plans to start releasing APIs for specific sections first, including a sports API that provides access to the paper’s database of salaries for players in Major League Baseball, the NBA, the NHL and other sports franchises. It will also be releasing data about best-selling books through its books API, and says it will be opening up other parts of its news operation through similar offerings later in the year.

It remains to be seen how much content USA Today provides through its interface, and on what terms. The New York Times only provides an excerpt of its content through its API, and doesn’t allow that content to be used in any venture designed for profit. National Public Radio, meanwhile, has provided full access to all of its content since 2008, and the organization is also working on a project with other publicly-funded entities to come up with a single system that provides access to all their data in one place. There is a tangible upside to an open API as well: NPR says its pageviews have climbed by 80 percent since it released its interface, as users click through from apps that use the service’s content.

KDYKES: It has been since late 2009 that I left my focus on API strategy for @vibe media to focus on growth of ScaleUp Technologies. With @vibe, we were on the right path – the strategy was/is solid. But, it is exciting to see such recognition of this model taking hold in companies of all kinds!

An example of how NOT to build API partners … FMyLife Starts Clamping Down On Its API, Has Some Developers Saying FML

Now, FMyLife disallowed paid applications and advertising when its API launched in February 2009, but the company has been inconsistent about enforcing those rules. Some developers have offered their applications with advertising for some time. And FMyLife has even approved the use of advertising and premium versions in some cases, without anticipating just how popular these applications could become. As it turns out, some of these applications have turned into big businesses in their own right, and some have proven to be drains on FMyLife’s servers. Rather than kill off all applications that are monetizing the service, FMyLife has decided it wants a cut.

KDYKES: Great example of a company who released an API with no real strategy or business structure in mind. Now they are in battle with partners using their API over revenue share – this is only the beginning & I suspect the varying law firms will make more revenue here than any of the players.

San Francisco Launches City App Store

Last month, at WordPress (WordPress) headquarters with leaders from the technology community, we launched DataSF.org. This new web site is designed to improve transparency in government, increase access to City data, and engage our highly skilled workforce to create apps from that data.

After the kick off there was a discussion about next steps for Gov 2.0 in San Francisco with Tim O’Reilly, Matt Mullenweg and other technology innovators. One idea was to create a City App Store to highlight and centralize programs created from City data. This has worked for Apple and Facebook, at last check; there are 60,000 apps available in the Apple App store and more than 350,000 different Facebook apps. Why not create a government app store as well?

KDYKES: It’s official – API’s are popping up everywhere. This is changing the face of the web & app development at a very rapid rate.

What’s next: an eHarmony for Travel? | VentureBeat

The following is a blog comment on a great VentureBeat article. It shows a bit about our perspective on use of the API to power partnerships & business development activities… and why it must be part of the strategic development & business model planning from the beginning.

Mark – Great article – extremely well researched. I also applaud that you put a heavy emphasis on the API partner program as part of the foundation. In my opinion, it should be part of the early strategic development plan for all SaaS co’s. In fact, for this idea, I see that as a go-to-market strategy prior to or instead of developing a destination site due to heavy costs of doing so.

A note to Reuven of Tripbase.com… yes, it would seem your app is definitely very close to Mark’s article thesis. Nice job on your service. Your partner program seems to be providing a great value-proposition, but also seems to be friction laden & would require a heavy traditional outbound sales approach for success. A couple of thoughts… (disclaimer: I’m a bit of an strategy geek & I realize you may have some of this in place)

Open a tiered API as a means of filling your business development pipeline. Use a solution like http://www.3scale.net to manage the tiered versions of the API and to manage monetization of the premium versions. Not suggesting you change your partner revenue model exactly – only widen & lower the barrier to entry to work with your solution.

First tier would be limited-use, perhaps non-commercial for dev. uses only, limited function/result set, result set would push to your travel site or with usage/time limits. Regardless, this tier 1 freely-available API will foster developer interest & allow them to work with your solution and create innovative uses that perhaps your team has not yet thought of. This engaged group becomes your target for the business dev team – inbound marketing at very little cost.

Higher tiers or premium uses could be monetized via metered use, flat monthly fees, per call or some combination. This can ultimately model your current revenue model of the partner program – just with lower friction in the partner development process.

Lastly, integrate a write component to the API and allow the network effect of your API partners to aggregate an ever growing set of inbound (of-course curated) data – allowing all partners to benefit from each other. See BazaarVoice and how they’ve done this with their aggregated product reviews solution.