<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: GET and POST aren&#8217;t verbs</title>
	<link>http://www.marcdegraauw.com/2007/06/05/get-and-post-arent-verbs/</link>
	<description>Some thoughts on meaning, the web and everything</description>
	<pubDate>Wed, 20 Aug 2008 18:33:25 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.2</generator>

	<item>
		<title>By: Daniel Silva</title>
		<link>http://www.marcdegraauw.com/2007/06/05/get-and-post-arent-verbs/#comment-2530</link>
		<author>Daniel Silva</author>
		<pubDate>Tue, 31 Jul 2007 23:34:03 +0000</pubDate>
		<guid>http://www.marcdegraauw.com/2007/06/05/get-and-post-arent-verbs/#comment-2530</guid>
		<description>(The form validator messed with the fake URL I was using in the example)

I forgot to mention that the "actions" resource would be the list of actions the cat does: walk, talk, whines, etc.</description>
		<content:encoded><![CDATA[<p>(The form validator messed with the fake URL I was using in the example)</p>
<p>I forgot to mention that the &#8220;actions&#8221; resource would be the list of actions the cat does: walk, talk, whines, etc.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Silva</title>
		<link>http://www.marcdegraauw.com/2007/06/05/get-and-post-arent-verbs/#comment-2529</link>
		<author>Daniel Silva</author>
		<pubDate>Tue, 31 Jul 2007 23:31:10 +0000</pubDate>
		<guid>http://www.marcdegraauw.com/2007/06/05/get-and-post-arent-verbs/#comment-2529</guid>
		<description>Hello.

I just want to comment on your cat example.

If you consider "cat" your resource, then GET, POST, PUT and DELETE (GPPD, for short) make sense. Your cat resource can be composed of many other resources, like for instance "actions". 

Then, your URI http:///cat/actions could answer to  GPPD calls and manage the actions that the cat resource is associated with. 

My point is that with some effort, you can model many things as Resources, it's a matter of finding the right abstractions, I suppose.</description>
		<content:encoded><![CDATA[<p>Hello.</p>
<p>I just want to comment on your cat example.</p>
<p>If you consider &#8220;cat&#8221; your resource, then GET, POST, PUT and DELETE (GPPD, for short) make sense. Your cat resource can be composed of many other resources, like for instance &#8220;actions&#8221;. </p>
<p>Then, your URI <a href="http:///cat/actions" rel="nofollow">http:///cat/actions</a> could answer to  GPPD calls and manage the actions that the cat resource is associated with. </p>
<p>My point is that with some effort, you can model many things as Resources, it&#8217;s a matter of finding the right abstractions, I suppose.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lars Marius Garshol</title>
		<link>http://www.marcdegraauw.com/2007/06/05/get-and-post-arent-verbs/#comment-1628</link>
		<author>Lars Marius Garshol</author>
		<pubDate>Thu, 07 Jun 2007 20:24:33 +0000</pubDate>
		<guid>http://www.marcdegraauw.com/2007/06/05/get-and-post-arent-verbs/#comment-1628</guid>
		<description>&#62; The problem is, this is not how the current Web works.

I couldn't agree more. When RESTafarians claim that REST obviously works because the web works so well they are missing the point, because, as you say, the current web doesn't use REST.

So there isn't really just a choice between SOAP and REST. The choice is really SOAP, REST, or plain HTTP. When we made the TMRAP Topic Maps "protocol" we gave it a SOAP interpretation and a plain HTTP interpretation. The latter was not REST by any stretch of the imagination, but it was exactly the way the current web works.

Of course, you could claim that REST is better, and for many situations it's true that REST is very clean, but it's not always convenient to make your web protocol RESTy.</description>
		<content:encoded><![CDATA[<p>&gt; The problem is, this is not how the current Web works.</p>
<p>I couldn&#8217;t agree more. When RESTafarians claim that REST obviously works because the web works so well they are missing the point, because, as you say, the current web doesn&#8217;t use REST.</p>
<p>So there isn&#8217;t really just a choice between SOAP and REST. The choice is really SOAP, REST, or plain HTTP. When we made the TMRAP Topic Maps &#8220;protocol&#8221; we gave it a SOAP interpretation and a plain HTTP interpretation. The latter was not REST by any stretch of the imagination, but it was exactly the way the current web works.</p>
<p>Of course, you could claim that REST is better, and for many situations it&#8217;s true that REST is very clean, but it&#8217;s not always convenient to make your web protocol RESTy.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
