HTTP Methods

• GET: Read
• POST: Create
• PUT: Update entire object
• PATCH: Partial update to the object
• DELETE: Delete
• OPTIONS: Get supported operations to the resource (Used for preflight)
• HEAD: Return HTTP header only
• TRACE: performs a message loop-back test along the path to the target resource, providing a useful debugging mechanism
• CONNECT: Starts two-way communications with the requested resource

Safe Methods

• https://developer.mozilla.org/en-US/docs/Glossary/Safe/HTTP
• It doesn’t alter the state of the server
• All safe methods are also idempotent
• Safe Methods include:
  • GET
  • HEAD
  • OPTIONS
  • TRACE
• Even if safe methods have a read-only semantic, servers can alter their state: e.g. they can log or keep statistics.
• What is important here is that by calling a safe method, the client doesn’t request any server change itself, and therefore won’t create an unnecessary load or burden for the server.
• Applications:
  • Browsers can perform pre-fetching without risk.
  • Web crawlers also rely on calling safe methods.
• For Safe Requests (not safe methods): CORS and Same Origin Policy

Idempotent Methods

• https://restfulapi.net/idempotent-rest-apis/
• https://developer.mozilla.org/en-US/docs/Glossary/Idempotent
• In mathematics, a function $f(x)$ is said to be idempotent when:
  • $fof=f$ which means $f(f(x))=f(x)\forall x\in Domain$
  • Example: abs(x): $||x||=|x|$
• Issuing a request once, or issuing it multiple times gives the same result which means there are no side effects.
• To be idempotent, only the state of the server is considered. The response returned by each request may differ. For example returning 404 after successful delete operation (200)
• Idempotent Methods include: Safe Methods + PUT + DELETE
  • GET
  • HEAD
  • OPTIONS
  • TRACE
  • PUT
  • DELETE
• PUT: First request will update the resource; the subsequent requests will just overwrite the same resource state again and again.
• DELETE: First request will delete (200), subsequent requests will return 404.
• POST: can trigger various side effects beyond just resource creation like sending notification, making changes to server state etc.
• PATCH: making partial updates. If you use a PATCH request to increment the number of items in a shopping cart, repeating the same PATCH request multiple times will increase the quantity with each request, which is a non-idempotent behavior.
• Applications:
  • Client can retry the request if it failed
• https://stackoverflow.com/questions/705782/why-shouldnt-data-be-modified-on-an-http-get-request
• https://stackoverflow.com/questions/48925525/why-http-method-put-should-be-idempotent-and-not-the-post-in-implementation-rest