<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wikidot="http://www.wikidot.com/rss-namespace">

	<channel>
		<title>Comments for page &quot;Let&#039;s stop kidding ourselves about APIs&quot;</title>
		<link>http://250bpm.com/blog:55/comments/show</link>
		<description></description>
				<copyright></copyright>
		<lastBuildDate>Sat, 01 Aug 2015 21:42:13 +0000</lastBuildDate>
		
					<item>
				<guid>http://250bpm.com/blog:55/comments/show#post-2350154</guid>
				<title>(no title)</title>
				<link>http://250bpm.com/blog:55/comments/show#post-2350154</link>
				<description></description>
				<pubDate>Sat, 01 Aug 2015 21:37:07 +0000</pubDate>
				<wikidot:authorName>martin_sustrik</wikidot:authorName>				<wikidot:authorUserId>939</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>The most critical rule, IMO, is the &quot;rule of three&quot;.</p> <p>But there's a lot of other rules (of thumb) to follow. This is quite a good presentation: <a href="http://lcsd05.cs.tamu.edu/slides/keynote.pdf">http://lcsd05.cs.tamu.edu/slides/keynote.pdf</a></p> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://250bpm.com/blog:55/comments/show#post-2350143</guid>
				<title>(no title)</title>
				<link>http://250bpm.com/blog:55/comments/show#post-2350143</link>
				<description></description>
				<pubDate>Sat, 01 Aug 2015 21:16:56 +0000</pubDate>
				<wikidot:authorName>Richard</wikidot:authorName>								<content:encoded>
					<![CDATA[
						 <p>Great post!! Can you recommend good resources that you came across re:API design?</p> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://250bpm.com/blog:55/comments/show#post-2350135</guid>
				<title>(no title)</title>
				<link>http://250bpm.com/blog:55/comments/show#post-2350135</link>
				<description></description>
				<pubDate>Sat, 01 Aug 2015 20:54:19 +0000</pubDate>
				<wikidot:authorName>martin_sustrik</wikidot:authorName>				<wikidot:authorUserId>939</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>Well, that's how it should be. Solve the political problem, then design the API based on that. But unfortunately, that's rarely the case.</p> <p>As for the monkey part, yes, it's an exageration. But let's be frank: It's not quntum physics. If you've been programiing for a decade or two you can probably hack together a bearable API. Assuming that the political aspect have been settled in advance, of course.</p> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://250bpm.com/blog:55/comments/show#post-2350127</guid>
				<title>(no title)</title>
				<link>http://250bpm.com/blog:55/comments/show#post-2350127</link>
				<description></description>
				<pubDate>Sat, 01 Aug 2015 20:40:45 +0000</pubDate>
				<wikidot:authorName>Britt M</wikidot:authorName>								<content:encoded>
					<![CDATA[
						 <p>Hi author,</p> <p>In your first sentence:</p> <blockquote> <p>&quot;I've browsed resources about API design&quot;.</p> </blockquote> <p>You go on to talk technically about how:</p> <blockquote> <p>&quot;APIs are just functions&#8230;&quot;</p> </blockquote> <p>and then how there can be</p> <blockquote> <p>&quot;messy APIs with ragged borders&#8230;&quot;</p> </blockquote> <p>So it would seem that you are pretty focused on <strong>building APIs and API design</strong>.</p> <p>API design is 0% political and 100% technical. How APIs are exposed, how they are organized, how they are developed, how they are documented - it's all technical - 0% political.</p> <p>The 100% political part happens at the product level where you have stakeholders pushing and pulling with each other on who the API is for. This is not API design. None of the product (political) stakeholders will tell any of the engineers how the <strong>design</strong> should look - because that's a technical issue.</p> <p>This is the least responsible statement in your article:</p> <blockquote> <p>&quot;solve it [politics] and the rest of it can be done by a monkey&quot;</p> </blockquote> <p>If all product politics surrounding an API are wiped out, I can guarantee you 100% that an API will not, and cannot, be properly <strong>designed</strong> and <strong>implemented</strong> <strong>technically</strong> by a monkey or even a junior developer for that matter.</p> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://250bpm.com/blog:55/comments/show#post-2347772</guid>
				<title>(no title)</title>
				<link>http://250bpm.com/blog:55/comments/show#post-2347772</link>
				<description></description>
				<pubDate>Tue, 28 Jul 2015 19:22:44 +0000</pubDate>
				<wikidot:authorName>martin_sustrik</wikidot:authorName>				<wikidot:authorUserId>939</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>Hi, good to know that there's someone out there who thinks about the problem. It's not at all that common.</p> <p>Anyway, it'll be hard to decompose politics into building blocks. Any system proposed will be gamed if it gets adopted. That's the nature of politics, I am afraid.</p> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://250bpm.com/blog:55/comments/show#post-2347758</guid>
				<title>(no title)</title>
				<link>http://250bpm.com/blog:55/comments/show#post-2347758</link>
				<description></description>
				<pubDate>Tue, 28 Jul 2015 19:02:49 +0000</pubDate>
				<wikidot:authorName>Kin Lane</wikidot:authorName>								<content:encoded>
					<![CDATA[
						 <p>The issues you discuss are real, and something being realized and worked on by many. Your title is linkbait. ;-)</p> <p>Politics of APIs - <a href="http://apievangelist.com/2014/03/17/politics-of-apis/">http://apievangelist.com/2014/03/17/politics-of-apis/</a><br /> Politics of the API Economy - <a href="http://apievangelist.com/2015/07/27/politics-of-the-api-economy/">http://apievangelist.com/2015/07/27/politics-of-the-api-economy/</a><br /> API Evangelist Thoughts On The Right To An API Key And Algorithmic Organizing - <a href="http://apievangelist.com/2014/09/06/api-evangelist-thoughts-on-the-right-to-an-api-key-and-algorithmic-organizing/">http://apievangelist.com/2014/09/06/api-evangelist-thoughts-on-the-right-to-an-api-key-and-algorithmic-organizing/</a></p> <p>I don't believe need to stop kidding ourselves about APIs, we need keep having discussions about why they work, why they don't, and the common building blocks that make things go around.</p> <p>Something I've been working on for over 3 years.</p> <p>Kin Lane</p> 
				 	]]>
				</content:encoded>							</item>
				</channel>
</rss>