<story><title>Let&apos;s remove verbs from HTTP 2.0</title><url>http://www.onebigfluke.com/2013/08/lets-remove-verbs-from-http-20.html</url></story><parent_chain><item><author>manarth</author><text>&amp;quot;Practically speaking there are only two HTTP verbs: read and write, GET and POST.&amp;quot;&lt;p&gt;And thus spoke someone who has never built a REST API, never used curl -I, and probably hasn&amp;#x27;t used anything other than a web browser to access HTTP content.&lt;p&gt;Sure, for the most part, we&amp;#x27;re all kinda new to REST, and we&amp;#x27;re slowly learning to construct good REST architecture. Sure, there&amp;#x27;s some redundant weird shit like SPACEJUMP. But we should aim to improve education and encouragement of the use of verbs such as PUT and DELETE, rather than abandon best practice because &amp;quot;no-one&amp;#x27;s going to use it&amp;quot; or YAGNI, when we can clearly see in talk after expert talk that these are the practices that are being recommended and already put to good use.&lt;p&gt;Not to mention the plethora of proxies, web servers, and tools that already support these accepted, recognised, standards-defined techniques.</text></item></parent_chain><comment><author>dewitt</author><text>&lt;i&gt;&amp;quot;And thus spoke someone who has never built a REST API&amp;quot;&lt;/i&gt;&lt;p&gt;Here are Brett&amp;#x27;s projects: &lt;a href=&quot;http://www.onebigfluke.com/&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.onebigfluke.com&amp;#x2F;&lt;/a&gt;&lt;p&gt;Maybe you&amp;#x27;ve heard of some of them? PubSubHubbub, Google App Engine, Camlistore, Google Consumer Surveys.</text></comment>
<story><title>Let&apos;s remove verbs from HTTP 2.0</title><url>http://www.onebigfluke.com/2013/08/lets-remove-verbs-from-http-20.html</url></story><parent_chain><item><author>manarth</author><text>&amp;quot;Practically speaking there are only two HTTP verbs: read and write, GET and POST.&amp;quot;&lt;p&gt;And thus spoke someone who has never built a REST API, never used curl -I, and probably hasn&amp;#x27;t used anything other than a web browser to access HTTP content.&lt;p&gt;Sure, for the most part, we&amp;#x27;re all kinda new to REST, and we&amp;#x27;re slowly learning to construct good REST architecture. Sure, there&amp;#x27;s some redundant weird shit like SPACEJUMP. But we should aim to improve education and encouragement of the use of verbs such as PUT and DELETE, rather than abandon best practice because &amp;quot;no-one&amp;#x27;s going to use it&amp;quot; or YAGNI, when we can clearly see in talk after expert talk that these are the practices that are being recommended and already put to good use.&lt;p&gt;Not to mention the plethora of proxies, web servers, and tools that already support these accepted, recognised, standards-defined techniques.</text></item></parent_chain><comment><author>seiji</author><text>In my mind, two HTTP methods exist: encode things in the URI or encode things in the body of a request.&lt;p&gt;Go read the RFC definition of PUT and report back.  I can never understand it.  If anything, PUT needs to be retired in favor of something unambiguously specific like CREATE.  In fact, why not go all the way and make all HTTP  methods just CREATE, READ, UPDATE, DELETE?  That&amp;#x27;s the only change I (as a nobody) could get behind.&lt;p&gt;We&amp;#x27;re not kinda new to REST.  REST has formally been around since 2000 and people have been using it heavily since a little before 2008.&lt;p&gt;Browsers seem to not want to support anything other than GET&amp;#x2F;POST in forms, so we hack it with running other methods over GET with _method params.  Why bother?  Just use GET&amp;#x2F;POST and let the endpoint denote what your intentions are, then have the server side code validate, perform the operations, return results, etc.&lt;p&gt;(Still rambling: I think one reason REST methods (not URL structure) bother me is it allows lazy (or inexperienced, or incapable) server side programmers to just allow what the client wants.  Oh, the client wants to DELETE?  Sure.  They know what they&amp;#x27;re doing.  No ACL&amp;#x2F;ownership checks needed).  Removing the ability of the client to forcefully say &amp;quot;CREATE&amp;#x2F;DELETE&amp;quot; may (&lt;i&gt;may&lt;/i&gt;) remind the programmer (who is in an outsourced operation in CantProgramistan) they are responsible for the data, not the client asking (asking, not demanding) for operations on the data.)</text></comment>