CODEWITHSUNDEEP
restapi
AKon
AKon

Reputation: 1

Idempotent API?

I'm creating a new REST based API that allows a client to query and retrieve the status of a transaction (that they sent or created earlier). Its an ability for the client to query and get the status of the transaction. The transaction itself could change its state over its life-cycle i.e. initially its approved, later it could be reversed etc. due to back-office or other operations.

When the client will make the call to this query API, depending on when they make the call during the life-cycle of the transaction, they will get the details of the transactions and the history of the states(approved, reversed etc). The API response could vary depending on when the call is made. Does this API qualify as an "Idempotent" API?

Thanks in advance!!

Upvotes: 0

Views: 110

Answers (1)

Not a real meerkat
Not a real meerkat

Reputation: 5739

It does. According to RFC 2616: 9.1.2 Idempotent Methods:

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

The key here is "side-effects". Since your requests don't change the state of your API as a side-effect, any number of them should have the same effect as a single one.

Upvotes: 1

Related Questions