The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource may be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

[via w3.org/Protocols/rfc2068]

links:
http://www.markbaker.ca/2002/08/HowContainersWork/
http://www.xml.com/pub/a/2004/12/01/restful-web.html

@IMHO:

you do mention the flickr-api. but in my opinion this is not REST like you describe it in your article. flickr has a single service point, and is always using GET methods. (except for uploading fotos, where they use POST) But the power of flickr is that it's so basic to use. just EVERY scripting language / enviroment is able to implement this. as soon as you start to rely on excotic HTTP methods, HTTP-header info, HTTP-Auth, or similiar concepts, people will fail to be able to implement your api.

another problem with rest are its many concepts. there should be a process where at least some stuff gets standardised, or recommended. for example authentication, error handling, xml-formats, use of HTTP-methods. A service could say: "we are using concept A for authentication, concept X for error handling, but we are using our own xml-syntax for responses..." so if you start implementing such an API you could at least use some basic libs for your desired language.