post is not idempotent, but it is a disadvantage

POST method is not idempotent , that if the client requests more than one time then it stop him .

But what if the client intensley requests the second time ?

and

why the POST is indempotent ???

I think if client deliberately submits a POST a second time then there is nothing to stop him, but its the responsibility of the developer to give user a hint or a message that this request is unsafe. For example in online banking transactions when user confirms a transaction then a message is shown to user saying "not to refresh or press back button on browser".

There is a good definition of these Safe and Idempotent methods here.

Piyush Joshi wrote:I think if client deliberately submits a POST a second time then there is nothing to stop him, but its the responsibility of the developer to give user a hint or a message that this request is unsafe. For example in online banking transactions when user confirms a transaction then a message is shown to user saying "not to refresh or press back button on browser".

There is a good definition of these Safe and Idempotent methods here.

the same thing we can do with GET method with quite midification when we call the doGet() method (I mean we can check for the repeat transaction with a program) .

why the POST is indempotent

POST requests are not required to be idempotent; they're generally used to affect a change of state (like increment a counter) - doing that twice can't result in the same state as doing it once.

Piyush Joshi wrote:its the responsibility of the developer to give user a hint or a message that this request is unsafe.

The proper way to do this is to prevent the user from submitting a request a second time. This could be done by passing a hidden parameter in the form which is good for only a single transaction.

Piyush Joshi wrote:For example in online banking transactions when user confirms a transaction then a message is shown to user saying "not to refresh or press back button on browser".

Which is actually the lazy/sloppy way to do things (but hey, as long as it's THEM that ends up with double the money, do they care?).

You can prevent stuff like this with a little careful design. For example, a thread-safe semaphore bound to a transaction ID and some logic/configuration that ensures that the same transaction isn't applied twice.