Home/ Questions/Q 826489
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T03:25:22+00:00

I know you don’t want to POST a form with a username and password

  • 0

I know you don’t want to POST a form with a username and password where anyone could use the history to see or situations where repeat actions may not be desired (refreshing a page = adding an item to a cart may not be desired). So I have an understanding when I may want to use one over the other. But I could always have the server redirect the URL after a GET to get around the cart problem and maybe most of my forms will work perfectly fine with GET.

Why should I use POST over GET? I don’t understand the benefits of one over the other. I do notice POST doesn’t add data to the history/URL and will warn you about refreshing the page, but those are the only two differences I know of. Why as a developer might I want to use one over the other?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Every HTTP method: POST, GET, PUT, DELETE, etc. caries its own semantics. When choosing the right method it is important to understand the HTTP and REST, since it is the way HTTP was meant to work and the way underlying network infrastructure operates.

    A good tutorial on REST is available here. Here is what is says about POST and GET methods:

    • Because the same interface is used for every resource, you can rely on being able to retrieve a representation — i.e., some rendering of it — using GET. Because GET’s semantics are defined in the specification, you can be sure that you have no obligations when you call it — this is why the method is called “safe”. GET supports very efficient and sophisticated caching, so in many cases, you don’t even have to send a request to the server. You can also be sure that a GET is idempotent — if you issue a GET request and don’t get a result, you might not know whether your request never reached its destination or the response got lost on its way back to you.

      The idempotence guarantee means you can simply issue the request again. Idempotence is also guaranteed for PUT (which basically means “update this resource with this data, or create it at this URI if it’s not there already”) and for DELETE (which you can simply try again and again until you get a result — deleting something that’s not there is not a problem). POST, which usually means “create a new resource”, can also be used to invoke arbitrary processing and thus is neither safe nor idempotent.

    • 0