<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Content aggregation: Am I missing something?</title>
	<atom:link href="http://www.onlineaspect.com/2007/06/18/content-aggregation-am-i-missing-something/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.onlineaspect.com/2007/06/18/content-aggregation-am-i-missing-something/</link>
	<description>a blog about building stuff on the web</description>
	<lastBuildDate>Mon, 09 Jan 2012 18:55:04 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
	<item>
		<title>By: Tom Chikoore</title>
		<link>http://www.onlineaspect.com/2007/06/18/content-aggregation-am-i-missing-something/comment-page-1/#comment-9</link>
		<dc:creator>Tom Chikoore</dc:creator>
		<pubDate>Tue, 19 Jun 2007 04:31:32 +0000</pubDate>
		<guid isPermaLink="false">http://onlineaspect.com/2007/06/18/content-aggregation-am-i-missing-something/#comment-9</guid>
		<description>Great post, I would like to add my own $0.02

I like the fact that more and more web properties are exposing an API for other developers to use.  I agree with you that you are at the mercy of the API provider but this is nothing new. This has been going on for a long time on the desktop. In the 90s, on the desktop it was common to have your app broken because of an API change but this has gotten better since the late 90s. I think the web is still experiencing what was going on on the desktop in the 90s. 

Speaking as person who has written a major API that is used by thousands of developers worldwide, these are some of the rules that I followed in order not have irate developers.  i) Remember the &#039;I&#039; in API stands for Interface.  For the most part interfaces should be immutable.  For me, an interface IS immutable period (that’s why I put in a lot of thought before publishing an interface). This means that the interface should not change.  If you want to change an interface, extend the current one and make a new interface.  I also call this the &quot;_ex&quot; rule because when you look at most APIs on the desktop, you will see the ones with “_ex”, for the most part, these are the interfaces that have been extended.  If you keep this rule you will not break your developers’ code. This also gives the user base time and a migration path to the new API.  If the old API is to be obsolete, give the user base enough notice and clearly state the date or release or version that an API will be obsolete ii) if its so happens that you need to change the behavior of a current interface for some reason and you cannot extend the current interface, then publicize, publicize, publicize your intentions over and over and over again to your user base. Obviously if you are fixing a bug you do not need to extend the current interface but notify your user base.

What I am seeing right now with the Facebook issue is that the notion of APIs is still in its infancy in the on the web.  I would personally NOT shy away from using these APIs because, the way APIs are published for the web will mature soon and these nuances will go away.  Just a side note:  if web services were being implemented as originally spec&#039;ed with the use of UDDI, the mutating API problem would be lessened because it would be harder (due to process and maybe SLAs) to change a published API.

From my experience, an API should be published with a good SLA or Licensing Agreement in good faith by the provider.  Even though most of these agreements mention that the API may change at any time without notice, what we have done in the past is to respect our user base and taking great steps to avoid inconveniencing the developers using our API.  I know some web properties offer some form of SLA or usage agreements today.</description>
		<content:encoded><![CDATA[<p>Great post, I would like to add my own $0.02</p>
<p>I like the fact that more and more web properties are exposing an API for other developers to use.  I agree with you that you are at the mercy of the API provider but this is nothing new. This has been going on for a long time on the desktop. In the 90s, on the desktop it was common to have your app broken because of an API change but this has gotten better since the late 90s. I think the web is still experiencing what was going on on the desktop in the 90s. </p>
<p>Speaking as person who has written a major API that is used by thousands of developers worldwide, these are some of the rules that I followed in order not have irate developers.  i) Remember the &#8216;I&#8217; in API stands for Interface.  For the most part interfaces should be immutable.  For me, an interface IS immutable period (that’s why I put in a lot of thought before publishing an interface). This means that the interface should not change.  If you want to change an interface, extend the current one and make a new interface.  I also call this the &#8220;_ex&#8221; rule because when you look at most APIs on the desktop, you will see the ones with “_ex”, for the most part, these are the interfaces that have been extended.  If you keep this rule you will not break your developers’ code. This also gives the user base time and a migration path to the new API.  If the old API is to be obsolete, give the user base enough notice and clearly state the date or release or version that an API will be obsolete ii) if its so happens that you need to change the behavior of a current interface for some reason and you cannot extend the current interface, then publicize, publicize, publicize your intentions over and over and over again to your user base. Obviously if you are fixing a bug you do not need to extend the current interface but notify your user base.</p>
<p>What I am seeing right now with the Facebook issue is that the notion of APIs is still in its infancy in the on the web.  I would personally NOT shy away from using these APIs because, the way APIs are published for the web will mature soon and these nuances will go away.  Just a side note:  if web services were being implemented as originally spec&#8217;ed with the use of UDDI, the mutating API problem would be lessened because it would be harder (due to process and maybe SLAs) to change a published API.</p>
<p>From my experience, an API should be published with a good SLA or Licensing Agreement in good faith by the provider.  Even though most of these agreements mention that the API may change at any time without notice, what we have done in the past is to respect our user base and taking great steps to avoid inconveniencing the developers using our API.  I know some web properties offer some form of SLA or usage agreements today.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

