POST vs. PUT is convention. Independent of the HTTP protocol, the actual server-side application logic is what matters. Example 1: you can code a request hand

POST vs. PUT is convention. Independent of the HTTP protocol, the actual server-side application logic is what matters. Example 1: you can code a request handler for a PUT that doesn't behave idempotently, and a POST that does. Example 2: you can code a handler that creates non-existing records with either a PUT or POST. It'll be confusing (especially Ex.2), but it's doable. --- PUT and POST have request bodies. And as GET requests, they can send data in the URI (in the query string). But the convention is not to do that in PUT and POST requests. But unconventionally, you can implement app logic to consume the query string data in a PUT or POST. Furthermore, you can include a body in a GET request, maybe a Web-Application Firewall rejects the request, but HTTP-wise you can send it, although it'll be unconventional. --- In other words, consider the HTTP (v1.1) message format: <REQUEST LINE> (e.g. POST /add-user HTTP/1.1) <HEADERS> (e.g. Host: http://example.com) <BODY> {"name":"John"} * "POST" or "PUT" the difference is just that string. * /add-user could also have a qs -> /add-user?foo=bar * Think of the <BODY> as optional (it goes after the <HEADERS> and two newlines). --- Good luck in your exam.