|
|
|
18 Aug 2006
Hybrid Analysis 3: API’s
API's are the usual suspect for creating hybrid applications. The idea is that an application communicates with a server on the Internet. An API would allow an application to get/retrieve or post information. And nothing new here, as this idea is the basis of many classic Internet service.
I guess the poster child should be email here, with the SMTP and POP/IMAP protocols/API's. Email API's are based on formally defined standards. And there are more of such standards.
Recent API's however sidestep a formal process for standardisation, and just publish their API's. And when such recent API's get traction, they might turn into de-facto standards. There are several examples for such API's.
A good example is the MetaWeblog API for posting blog items to blogging services. I guess that one could call this already a de-facto API. Under MacOSX applications like MarsEdit or Ecto support this API.
Another example is Del.icio.us, with applications like WebnoteHappy or Cocoalicious. These applications retrieve and post bookmark Items to the del.icio.us service. This could become a de-facto API when other bookmarks service support the same API. But for the moment I call it a closed API.
A drawback of API's, is that the application developer has to implement a closed API for each service that he wants to support. Once an API becomes de-facto, the application developer can create functionality such that the user can add any service that supports the API.