<?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: Resource Types</title>
	<atom:link href="http://www.subbu.org/blog/2008/12/resource-types/feed" rel="self" type="application/rss+xml" />
	<link>http://www.subbu.org/blog/2008/12/resource-types</link>
	<description>HTTP, REST and some Cycling</description>
	<lastBuildDate>Wed, 21 Jul 2010 08:57:31 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: subbu</title>
		<link>http://www.subbu.org/blog/2008/12/resource-types/comment-page-1#comment-14790</link>
		<dc:creator>subbu</dc:creator>
		<pubDate>Wed, 24 Dec 2008 16:23:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.subbu.org/?p=763#comment-14790</guid>
		<description>JJ: 

&lt;blockquote&gt;The other issue I see with overloading media types is that it seems that media types are the only possibility for a decent versioning strategy in REST and unfortunately the combinatorial aspect of overloading media types for different usages could result in an explosion of media types.&lt;/blockquote&gt;

Media types are indeed central to versioning. Unfortunately, most APIs out there rely on URIs for versioning, which does not work.

However, I am not convinced that &quot;explosion of media types&quot; is a problem.</description>
		<content:encoded><![CDATA[<p>JJ: </p>
<blockquote><p>The other issue I see with overloading media types is that it seems that media types are the only possibility for a decent versioning strategy in REST and unfortunately the combinatorial aspect of overloading media types for different usages could result in an explosion of media types.</p></blockquote>
<p>Media types are indeed central to versioning. Unfortunately, most APIs out there rely on URIs for versioning, which does not work.</p>
<p>However, I am not convinced that &#8220;explosion of media types&#8221; is a problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jean-Jacques Dubray</title>
		<link>http://www.subbu.org/blog/2008/12/resource-types/comment-page-1#comment-14743</link>
		<dc:creator>Jean-Jacques Dubray</dc:creator>
		<pubDate>Wed, 24 Dec 2008 03:57:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.subbu.org/?p=763#comment-14743</guid>
		<description>Subbu:

I think we should start 2009 by running an &quot;actus fidei&quot; and burn WS-I for ever. There is not a document that is more anti-SOA than WS-I Basic Profile.

Couldn&#039;t we use endpoints efficiently to avoid the kinds of problems you are talking about? (e.g. one end point per service and not one per ESB). Ultimately, stitching SO on top of OO or other primitive forms of computing languages is not going to help solve that problem.  

The other issue I see with overloading media types is that it seems that media types are the only possibility for a decent versioning strategy in REST and unfortunately the combinatorial aspect of overloading media types for different usages could result in an explosion of media types.</description>
		<content:encoded><![CDATA[<p>Subbu:</p>
<p>I think we should start 2009 by running an &#8220;actus fidei&#8221; and burn WS-I for ever. There is not a document that is more anti-SOA than WS-I Basic Profile.</p>
<p>Couldn&#8217;t we use endpoints efficiently to avoid the kinds of problems you are talking about? (e.g. one end point per service and not one per ESB). Ultimately, stitching SO on top of OO or other primitive forms of computing languages is not going to help solve that problem.  </p>
<p>The other issue I see with overloading media types is that it seems that media types are the only possibility for a decent versioning strategy in REST and unfortunately the combinatorial aspect of overloading media types for different usages could result in an explosion of media types.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
