Call for ideas: What would you like to do with APIs?

[jducoeur]

[Mostly for the techies]

I was just reading this recent article in TechCrunch -- it's light on detail, but makes the likely-correct point that APIs are going to become ever more important in the industry in coming years. So I'm pondering: what should Querki be doing with them?

At the highest level, the notion's been around for a while -- I think Galen mentioned the idea of API integration a couple of years ago now -- but Querki's original architecture wasn't API friendly because the QL processing pipeline was too synchronous. Now that that's fixed, I don't think there's any reason we *can't* build API integration into Querki, allowing a Querki Space to call APIs of external services. I'm just not sure what it *means* yet, and my rule for Querki is that I don't build features until I have clear use cases.

(NB: I'm specifically talking about Querki Spaces calling external APIs here. Querki itself already exposes an extremely rich API -- the rewrite I've done over the past year effectively means that Querki is *entirely* API-based, and simply provides a standard Client for working with those APIs. They're nowhere near stable enough yet, and are completely lacking stuff like documentation, examples, validation suites and all those elements you need in order to make an API real, but under the hood everything is now driven by a straightforward JSON API that you can code to.)

Anyway: I'm looking for ideas. Querki by now makes it fairly easy to build Spaces for your data needs; my current Spaces include things like:

• Kate's Gallery of Cross-Stitch Projects


• LARP development and management


• The public Period Games Homepage, with links to a zillion pages on the topic, organized by Game, Source, Topic and so on


• The new (still in progress) Carolingian Cooks Guild database of recipes


• My personal Filk Songbook


• House Lochleven's Inventory Management Space

Etc, etc, etc -- basically, small collaborative websites that let you collect, organize and share information about some topic.

The question is, in what ways would API access make this better? What could you do more easily in this world, if you could, reasonably easily, tell Querki to go out and do *something* with a particular API from some other service?

None of this is going to happen soon, mind -- I have lots of more-critical irons in the fire at the moment. But I'd like to add some examples to Querki's Use Cases, to help understand where we should eventually be going with API access.

So the floor is open for brainstorming. Anybody got suggestions? Anything data-centric you've always wanted to build, that would work best if you could mix in specific outside data?

Comments

[laurion]

Zapier is like IFTTT, yes.

RSS is one of my principle and preferred ways of moving data into my consumption stream, so I'm glad to hear it is in the works.

[jducoeur]

Yeah -- I figure, there's a standard protocol for what we want to do, which is well-supported all around, so that's the logical way to deal with it.

Mind, I may wind up with special modules to put these notifications directly into, eg, the Facebook stream as well; I may have little choice, in order to get the desired behavior there. But first things first -- RSS is the *right* way to do it, so it ought to come first.