<?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"
	>
<channel>
	<title>Comments on: (Another) Rest Controller for Rails</title>
	<atom:link href="http://pezra.barelyenough.org/blog/2006/03/another-rest-controller-for-rails/feed/" rel="self" type="application/rss+xml" />
	<link>http://pezra.barelyenough.org/blog/2006/03/another-rest-controller-for-rails/</link>
	<description></description>
	<pubDate>Sun, 27 Jul 2008 00:53:42 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: stone mind &#187; toward a RESTful approach to Django applications</title>
		<link>http://pezra.barelyenough.org/blog/2006/03/another-rest-controller-for-rails/#comment-11267</link>
		<dc:creator>stone mind &#187; toward a RESTful approach to Django applications</dc:creator>
		<pubDate>Thu, 01 Mar 2007 11:45:37 +0000</pubDate>
		<guid isPermaLink="false">http://pezra.barelyenough.org/blog/?p=218#comment-11267</guid>
		<description>&lt;p&gt;[...] Or, consider this discussion from Peter Williams&#8217; blog about how to handle a POST that fails validation in the section &#8220;Handling Bad Data&#8221;:  The fundamental problem here is that the separate editor resource will PUT the modified resource when you click save/submit. But what if you messed it up and, say, violated the business rule that blue products must have a price that is divisible by three? In a normal Rails app that proposed change would fail validation and the update action would just re-render the edit page with bad fields highlighted. But in a RESTful world the editor and the validation code are separate and it is wrong from REST stand point to just render the editor resource from in response to a product resource request. However, if you don’t do that you need to get the form data, and which fields are bad, from the previous attempt so that you can re-render the editor with the information the user previously entered and what was wrong with it. [...]&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>[&#8230;] Or, consider this discussion from Peter Williams&#8217; blog about how to handle a POST that fails validation in the section &#8220;Handling Bad Data&#8221;:  The fundamental problem here is that the separate editor resource will PUT the modified resource when you click save/submit. But what if you messed it up and, say, violated the business rule that blue products must have a price that is divisible by three? In a normal Rails app that proposed change would fail validation and the update action would just re-render the edit page with bad fields highlighted. But in a RESTful world the editor and the validation code are separate and it is wrong from REST stand point to just render the editor resource from in response to a product resource request. However, if you don’t do that you need to get the form data, and which fields are bad, from the previous attempt so that you can re-render the editor with the information the user previously entered and what was wrong with it. [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: RESTful Rails, simply_restful,...</title>
		<link>http://pezra.barelyenough.org/blog/2006/03/another-rest-controller-for-rails/#comment-4820</link>
		<dc:creator>RESTful Rails, simply_restful,...</dc:creator>
		<pubDate>Fri, 08 Dec 2006 01:26:36 +0000</pubDate>
		<guid isPermaLink="false">http://pezra.barelyenough.org/blog/?p=218#comment-4820</guid>
		<description>&lt;p&gt;[...] REST is all about resources, remember? SOAP and all other kinds of RPC are evil and we came to the conclusion that a well-defined domain model plus four standard methods of communicating with its instances are key, right? Why the heck are the endpoints to our RESTful URIs still Controllers? Why do we define behavior here &#8211; isn&#8217;t REST about data? [...]&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>[&#8230;] REST is all about resources, remember? SOAP and all other kinds of RPC are evil and we came to the conclusion that a well-defined domain model plus four standard methods of communicating with its instances are key, right? Why the heck are the endpoints to our RESTful URIs still Controllers? Why do we define behavior here &#8211; isn&#8217;t REST about data? [&#8230;]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
