<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Every Noun Can Be Verbed...</title><link>http://blogs.msdn.com/pathelland/archive/2007/06/12/every-noun-can-be-verbed.aspx</link><description>As I watch the REST versus non-REST discussion, it occurs to me that there are a number of aspects to the debate. While I am not attempting to address all of these aspects, I think that part of the discussion revolves around DATA versus BEHAVIOR. When</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>Web Things, by Mark Baker  &amp;raquo; Blog Archive   &amp;raquo; Nouns, verbs, oh my!</title><link>http://blogs.msdn.com/pathelland/archive/2007/06/12/every-noun-can-be-verbed.aspx#3274031</link><pubDate>Wed, 13 Jun 2007 23:39:49 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:3274031</guid><dc:creator>Web Things, by Mark Baker  » Blog Archive   » Nouns, verbs, oh my!</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://www.markbaker.ca/blog/2007/06/13/nouns-verbs-oh-my/"&gt;http://www.markbaker.ca/blog/2007/06/13/nouns-verbs-oh-my/&lt;/a&gt;&lt;/p&gt;
</description></item><item><title>re: Every Noun Can Be Verbed...</title><link>http://blogs.msdn.com/pathelland/archive/2007/06/12/every-noun-can-be-verbed.aspx#3309159</link><pubDate>Fri, 15 Jun 2007 11:26:30 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:3309159</guid><dc:creator>fuzzyBSc</dc:creator><description>&lt;p&gt;I think that the application of business logic to CRUD-submitted or REST-submitted data is absolutely the norm. It is easy to confuse the concepts of REST as an interface control model and a database-like relational implementation. It is the interface between components of the architecture that REST attempts to reign in. What a service chooses to do with its own data is its own prerogative.&lt;/p&gt;
&lt;p&gt;While the discussion of nouns and verbs is easy to understand initially, I think it is an ultimately unsatisfying dichotomy. I take a more protocol-oriented approach, separating object identification, interaction and content. A GET interaction, for example, is not simply a noun or a method. A GET interaction incorporates protocol information such as headers, and I think also really incorporates possible response messages. Messages are exchanged between an anonymous client and identified resource object. REST ultimately says that it is valuable to separate the set of objects, the set of interactions that can transfer content between clients and objects and the set of content types that are transferred. It says that these should be decoupled so that they can evolve separately.&lt;/p&gt;
&lt;p&gt;It isn't really a clash between nouns and content types. It is a clash between uniform interactions with a set of objects and non-uniform interactions with a different set of objects. Non-uniform interactions can be folded onto a smaller set of objects, but doing so harms interoperability and evolvability of interactions.&lt;/p&gt;
&lt;p&gt;I think it is the decoupling of interaction and content that really separates REST from traditional SOA and from traditional CRUD. Traditional SOA makes content subordinate to interactions, by placing parameter lists within the definition of its methods. That means that the total number of methods will equal the number of interactions x the number of content types, and may be multiplied out by the number of identifiers also. This reduces the overall feasibility of a uniform interface. Traditional CRUD decouples method and content type, but relies on atomic content combined with transactions. REST tends to rely on higher-level content types, such as HTML or more semantic-intensive content types. This reduces the reliance of REST on transactions and stateful interaction.&lt;/p&gt;
&lt;p&gt;REST walks a middle line between traditional CRUD and traditional SOA, hopefully obtaining the benefits of CRUD's interoperability as well as SOA's technology independence, plus many of its own benefits.&lt;/p&gt;
&lt;p&gt;Benjamin&lt;/p&gt;</description></item></channel></rss>