REST: correct response status according RFC 2616 HTTP/1.1 spec?

Question

I have skimmed over the HTTP/1.1 protocol spec at RFC-2616 and I am trying to understand which status code should be returned when a particular REST method is invoked. As far as I have studied the protocol (links), I tried to parse REST methods to the correct status code:

• GET
  • to return 200 (ok) in case at least one resource is found.
  • should I return 204 (not found) if nothing is found (i.e. empty list is returned)?
• PUT
  • to return 200 (ok) or 204 (not found) based if the resource is modified or not
  • moreover to return 501 (unimplemented) if the request is malformed or not understood.
• POST
  • the same like PUT method with the difference the 201 (created) is returned if the new reource has been added to the orign
  • based on common recommendation, POST sould be used for creating a new reource, PUT for modifying an existing one. If I decide follow this recommendation, what should I return in case of attempt to modify an existing resource ex. POST api/v1/person/1?
• PATCH
  • the same like PUT method with the difference it doesn't replace the whole resource like PUT does, but itmodifies a resource partially
  • there is no word about PATCH REST method in W3 protocol RFC-2616, should it be treated the same like PUT?
• DELETE
  • to return 200 (ok) if the resource was deleted and [204 (not found)] in case there is no resource existing to remove (id not found). Does it copy the GET responses principe in case of REST implementation?

Is my "table" correct (especially the statements with the quotation marks ?? Is right that only GET should return the request itself in the body and the rest of methods just an URI link to an amended resource (new added, modified..) included in the header?

Is my understanding correct and does exist another source describing REST methods officially which is recommended (or are we "obligated") to follow? I am quite confused of wide range of sources giving me a bit different answers to each method as well of this really verbose RFC-2616 protocol.

The best would be the existence of a table describing briefly and clearly all these 5 methods with possibilites of status returned, body content and headers.

Answer 1

From RFC 7230

This HTTP/1.1 specification obsoletes RFC 2616

So any attempt to work out patterns for status codes should start from there

Is my "table" correct

Not really; take a look at Kropat's (unofficial) flow charts in Stop Making it Hard.