APIs are the lifeblood of mashups. I speculated here 5 years ago that manually assembled API directories (ProgrammableWeb being the apex of examples) were probably going to be supplanted by automated directories at some point. Then I waited… and waited…
It wasn’t happening; no one seemed to see the potential here. So recently, I decided to get down to business and try and solve the problem myself. The result is APIHound, the web’s largest API directory.
Over 50,000 APIs are in the searchable directory (or you can browse by category). It’s still a work in progress as you can read here. Among other features, I’d like to add the ability to bookmark/favorite cool APIs you discover and include a “featured API” widget on the homepage.
I think the site’s off to a great start though, so check it out!
Hey, getting back to mashup-related stuff (again, posting over at SearchSOA)
Check out my guest post over at SearchSOA
My latest post over at SearchSOA, When Do I Get to Build My Own Portal, , describes an interesting mashup use case. We don’t often think of portals as mashups, because there is this notion that a mashup communicates information via a single point.
For example, in the classic “Show me nearby apartments on a map” mashup, the two underlying components may be craiglist and Google Maps. But you only see 1 output: A map with data points on it. A portal typically has a bunch of “little boxes” (portlets) that can be populated from a variety of different places, and they don’t necessarily interact with one another. So is it even proper to call a portal a mashup?
I think so. Although there might not be integration at the data level, the fact is the various portlets are mashed together at the presentation level. A portal provides a unified container to view disparate systems, even if the views inside that container aren’t necessarily mashed together. And the fact is that many “portal-enabling” tools that help you get content into a portal are in fact mashup products.
If you’ve read any of my previous posts, you know I am a big fan of users being able to create their own mashups inside corporate environments. I think that “self-serve IT” is the only way users will get many of the solutions they need since IT departments can’t afford to dedicate resource to every project out there. In my SearchSOA piece though, I might seem to contradict myself, since I don’t think users should build their own Portals.
My experience is that users who want a portal are really voicing a concern about information availability. If you just give them a portal framework, they will still have the same problem. You should attack the underlying issue first and expose more of the information your users want. If they then choose to build a portal with that data, so be it. But they might also build other tools (information dashboards, monitors, etc) that are actually what they really need. You don’t solve a problem by throwing a tool or a framework at it.