Should a RESTful HTTP request that does not directly lead to data manipulation but causes manipulation have a GET, PUT or POST action?

Question

Here is the question for you RESTful botany. Let me create a scene.

Say I have a remote ChickenShack system and a local system called BurgerShack, both of which are integrated in such a way that each system supports a “synchronized” copy of the entity data. When an object change occurs in ChickenShack, it sends a collection of identifiers for these objects as a RESTful request for BurgerShack. BurgerShack then issues a GET request to ChickenShack, requesting all attributes of the modified object and updates the local copy of the object.

All this is asynchronous and designed around certain restrictions (so if this is not pleasant for you, understand that sometimes in life we ​​should have shit and a smile).

My question is: should the initial request from ChickenShack on BurgerShack be a GET or PUT request? Since the original request is idempotent, part of me says "GET". However, this ultimately leads to a change in the data in Burger, so the other part of me says “PUT” or “POST”.

What do you think?

Answer 1

I would choose POST because:

• it changes state in BurgerShack (I don't think it's idempotent because it runs a GET from BurgerShack in ChickenShack).
• it does not create a new resource at this particular url (which excludes PUT )