Clarification on using Http PUT & POST and their differences - rest

Question

I found this good post about understanding Http PUT & POST.
http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/
So the take away from the post are:
PUT:
PUT puts a page at a specific URL. If there is already a page there, it’s replaced. If there’s no page, a new one is created.
PUT is a limited operation that never does anything more than PUT one page at a specified URL.
PUT should be used when the client specifies the location for the page. e.g giving id of the object in a database table.
POST:
POST sends some data to a specified URL. The server on the other end of this URL can do whatever it wants with this data. It can store it in a new page, It can insert, update, or delete records in a database, It can start brewing coffee etc.
POST is used when the client sends the page to the server, and the server then tells the client where it put it. e.g after insertion in database returns generated id.
All good, but I have following questions:
I know it is possible to create new objects using PUT. That means even if I don't specify the location or id where object should be put, PUT method works. So, the statement made by the author PUT should be used when the client specifies the location for the page makes little sense or unconvincing when deciding when to use PUT.
My second question is regarding this statement POST sends some data to a specified URL. The server on the other end of this URL can do whatever it wants with this data. But the same is possible with PUT method once the data has been received on the server. Which leads to conflict with his another statement PUT is a limited operation that never does anything more than PUT one page at a specified URL.
Finally, are Http methods(PUT, POST, GET etc) more of a design concept or have technical implications when used.

Answer 1

POST is used to create new object while PUT is used to update existing object.
If a server doesn't respect this rule it breaks the semantic.

Answer 2

Your question #3 is on the right track: The HTTP methods don't have a technical implication on their own, but display a certain intent. These are defined in for example RFC 7231 / Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Theoretically, nothing stops you from implementing software that listens on a DELETE to trigger something other than a delete, create new entities from a PUT or delete when receiving a POST. Is that useful? Probably not, but definitely not impossible.
The HTTP methods are well defined as a kind of contract how they should be used, to allow interaction between different software components.

Answer 3

The Page analogy you gave doesnt fit into the context of PUT and POST.
PUT,POST,GET,DELETE etc are all HTTP operations to do certain operations on a resource
Let us consider a simple resource , this enpoint is written by a pet house who wants to track dogs through a REST based back-end(server side software)
/dogs
When we want to add a dog to the records of dogs, we do a
POST /dogs with body
{
color:'black'
breed:'xyz'
puppies: 0
bla
bla
bla
}
It creates a new dog under /dogs resource with a unique identifier say identifier 1
Now the owner of the pet house wants to see all the dogs he/she has so the call made is
GET /dogs
This will list all the dogs and I can see what colour, what bred they are etc etc etc
I want to see a specific Dog, what do I call
GET /dogs/1 (Here 1 is the Identifier of the dog)
Which gives all details of Dog with identifier 1
Now let us say the Dog now gets married and has puppies (just so that it looks good socially) and we want to update the number of puppies to 3, what do you do
PUT /dogs/1 with body
{
color:'black'
breed:'xyz'
puppies: 3
bla
bla
bla
}
and now the record of Dog 1 is updated.
Now the unfortunate moment the Dog dies , the owner makes this call
DELETE /dogs/1 and that resource is deleted from the records.
Another thing to understand is PUT is idempotent POST is not which means if you do
POST /dogs for 10 times 10 different instances of dogs are created
if you do for 10 times
PUT /dogs/1 , it still does the same thing to that 1 dog.

Answer 4

HTTP methods are more about semantics than actual implementations (that answers your 3rd question I guess). I would suggest that don't take any single person's opinion literally.
In general, I believe the following is true
PUT
PUT needs an identifier in the url. And it will replace existing resource with whatever you provided. Replace here is important because, if you need partial updates, you should go for PATCH instead. If you expect the server to create a resource, you should call POST and not PUT. Calling a PUT with an imaginary id and expecting server to create the resource with that id does not make sense. Now this is what should be followed, but I have seen code which does otherwise just for convenience :)
POST
POST should always create a resource. If the resource with similar details already exists, service may choose to return some kind of error code to denote that (may be 400 or 409)