Thanks for your input on this as we always strive to be as accurate as we possibly can.
From my experience, I've always used PUT to "Put files onto the server". This probably has to do with my journey into cybersecurity. The first time I encountered PUT was in the context of uploading webshells. I was "PUT-ting" webshells on web servers.
After a little research, I found...
From https://www.w3schools.com/tags/ref_httpmethods.asp (emphasis mine)
"PUT is used to send data to a server to CREATE/update a resource."
"The HTTP PUT request method CREATES A NEW RESOURCE or replaces a representation of the target resource with the request payload."
" The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already
existing resource, the enclosed entity SHOULD be considered as a
modified version of the one residing on the origin server. If the
Request-URI does not point to an existing resource, and that URI is
capable of being defined as a new resource by the requesting user
agent, the origin server can create the resource with that URI. If a
new resource is created, the origin server MUST inform the user agent
via the 201 (Created) response. If an existing resource is modified,
either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
to indicate successful completion of the request. If the resource
could not be created or modified with the Request-URI, an appropriate
error response SHOULD be given that reflects the nature of the
problem. The recipient of the entity MUST NOT ignore any Content-*
(e.g. Content-Range) headers that it does not understand or implement
and MUST return a 501 (Not Implemented) response in such cases."
So, I think we're both correct on this one.
As far as POST goes, I think you're spot on. From what I understand, you can have query strings with POST, but that query string won't have anything to do with the POST data which is probably what was confusing me and I appreciate the heads-up.