<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>links.lmorchard.com - #post</title>
    <link>/tags/post/</link>
    <description>Recent bookmarks tagged #post</description>
    <lastBuildDate>Mon, 02 Nov 2026 08:24:52 +0000</lastBuildDate>
    <item>
      <title>PUT or POST: The REST of the Story « Open Sourcery</title>
      <link>http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story</link>
      <description>&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #http #post #put #rest #webdev&lt;/p&gt;</description>
      <pubDate>Sun, 20 Jun 2010 03:53:09 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:13591</guid>
      <category>http</category>
      <category>post</category>
      <category>put</category>
      <category>rest</category>
      <category>webdev</category>
    </item>
    <item>
      <title>PUT vs POST in RESTful Web Service « vincenthome’s Tech Clips</title>
      <link>http://vincenthomedev.wordpress.com/2008/12/18/put-vs-post-in-restful-web-service</link>
      <description>&#34;This explains when to use POST or PUT for creating new resources. The answer ultimately lies in who is responsible for determining the new resource’s URI. If the client is in charge, the client can use PUT to the new URI (like we did for user accounts) and the service can return a response code of 201 (“Created”). However, if the service is in charge of generating the new URI, the client should POST the new resource to a factory URI like we’ve done for bookmarks. Then, the service can return a response code of 201 (“Created”) along with the URI of the new resource in the response “Location” header.&#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #http #post #put #rest #webdev&lt;/p&gt;</description>
      <pubDate>Fri, 26 Dec 2008 20:13:46 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:11812</guid>
      <category>http</category>
      <category>post</category>
      <category>put</category>
      <category>rest</category>
      <category>webdev</category>
    </item>
    <item>
      <title>Django snippets: minimal nginx conf to split get/post requests</title>
      <link>http://www.djangosnippets.org/snippets/1141</link>
      <description>&#34;After a point the sql server becomes the bottleneck in lots of web application, and to scale, master-slave replication with single master, multiple slave is recommended. This setup with nginx can be used to accomplish traffic distribution between master and slave based on request method. &#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #config #get #http #master #nginx #post #scalability #slave #sysadmin #webdev&lt;/p&gt;</description>
      <pubDate>Wed, 15 Oct 2008 19:37:44 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:11541</guid>
      <category>config</category>
      <category>get</category>
      <category>http</category>
      <category>master</category>
      <category>nginx</category>
      <category>post</category>
      <category>scalability</category>
      <category>slave</category>
      <category>sysadmin</category>
      <category>webdev</category>
    </item>
    <item>
      <title>Why PUT and DELETE?</title>
      <link>http://www.artima.com/lejava/articles/why_put_and_delete.html</link>
      <description>&#34;In this interview, Elliotte Rusty Harold discusses the true meaning of PUT and DELETE.&#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #delete #get #http #post #put #rest #webdev&lt;/p&gt;</description>
      <pubDate>Fri, 29 Dec 2006 22:14:00 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:8315</guid>
      <category>delete</category>
      <category>get</category>
      <category>http</category>
      <category>post</category>
      <category>put</category>
      <category>rest</category>
      <category>webdev</category>
    </item>
  </channel>
</rss>
