<?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: ⇥ Software, APIs and all the king&#8217;s men</title>
	<atom:link href="http://blog.tabini.ca/2010/06/software-apis-and-all-the-kings-men/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.tabini.ca/2010/06/software-apis-and-all-the-kings-men/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=software-apis-and-all-the-kings-men</link>
	<description>Stumbling on since 1997</description>
	<lastBuildDate>Fri, 07 Oct 2011 08:06:16 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Chris Henry</title>
		<link>http://blog.tabini.ca/2010/06/software-apis-and-all-the-kings-men/comment-page-1/#comment-1307</link>
		<dc:creator>Chris Henry</dc:creator>
		<pubDate>Wed, 14 Jul 2010 05:23:57 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=629#comment-1307</guid>
		<description>As someone who has extracted an API from the existing codebase built specifically for the web, this is all great advice.  The lessons learned by having to make your data layers in multiple ways (Web, API) were learned hard.  Also, the amount of functionality that we found floating around in random scripts was astounding.

Just out of curiosity, what is your hardware architecture for your API layer?  Is it a middle layer that sits between the web app, various interfaces and the database?  Or is integrated with the codebase, with different URLs exposing different interfaces (Web, REST, etc.)</description>
		<content:encoded><![CDATA[<p>As someone who has extracted an API from the existing codebase built specifically for the web, this is all great advice.  The lessons learned by having to make your data layers in multiple ways (Web, API) were learned hard.  Also, the amount of functionality that we found floating around in random scripts was astounding.</p>
<p>Just out of curiosity, what is your hardware architecture for your API layer?  Is it a middle layer that sits between the web app, various interfaces and the database?  Or is integrated with the codebase, with different URLs exposing different interfaces (Web, REST, etc.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ivo</title>
		<link>http://blog.tabini.ca/2010/06/software-apis-and-all-the-kings-men/comment-page-1/#comment-1277</link>
		<dc:creator>Ivo</dc:creator>
		<pubDate>Mon, 28 Jun 2010 11:20:59 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=629#comment-1277</guid>
		<description>Good points.

When designing APIs from the start however, there are a few things to take into account. One is the way the API is designed. If you work from the data upwards, then you tend to end up with find grained APIs that allow a frontend to do anything, but with really poor performance and with many calls going back and forth between client and API. I promote &#039;scenario driven design&#039; where you look not just at your data structure, but at the scenario&#039;s that your clients are going to want to perform on them. For example &#039;registering a user&#039; is a scenario that multiple clients could need, so you would create API calls to cate user registration, rather than having a CRUD api around your user object. This leads to better designed and better performing APIs.</description>
		<content:encoded><![CDATA[<p>Good points.</p>
<p>When designing APIs from the start however, there are a few things to take into account. One is the way the API is designed. If you work from the data upwards, then you tend to end up with find grained APIs that allow a frontend to do anything, but with really poor performance and with many calls going back and forth between client and API. I promote &#8216;scenario driven design&#8217; where you look not just at your data structure, but at the scenario&#8217;s that your clients are going to want to perform on them. For example &#8216;registering a user&#8217; is a scenario that multiple clients could need, so you would create API calls to cate user registration, rather than having a CRUD api around your user object. This leads to better designed and better performing APIs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rajat Mittal</title>
		<link>http://blog.tabini.ca/2010/06/software-apis-and-all-the-kings-men/comment-page-1/#comment-1179</link>
		<dc:creator>Rajat Mittal</dc:creator>
		<pubDate>Tue, 22 Jun 2010 16:33:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=629#comment-1179</guid>
		<description>This is a great article and I cannot agree more. We are working on a project and were thinking along the same lines and this gives us more confidence going in that direction. Great job!</description>
		<content:encoded><![CDATA[<p>This is a great article and I cannot agree more. We are working on a project and were thinking along the same lines and this gives us more confidence going in that direction. Great job!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

