Should a RESTful HTTP request that doesn't directly result in data manipulation, but triggers manipulation, have an action of GET, PUT or POST?

Question

Here's a question for you RESTful nerds. Allow me to set the stage.

Say I have a remote system called ChickenShack and a local system called BurgerShack, both of which are integrated such that each system maintains a "synchronized" copy of entity data. When a change occurs to entities on ChickenShack, it sends a collection of the IDs of those entities as a RESTful request to BurgerShack. BurgerShack then issues a GET request to ChickenShack, requesting all the attributes of a changed entity and updates the local copy of the entity.

All of this is asynchronous and is designed around certain constraints (so if it tastes bad to you, realize that in life sometimes we have to eat shit and smile).

My question is: should the initial request issued from ChickenShack to BurgerShack be a GET or a PUT request? Since the initial request is idempotent, part of me says "GET". Yet, it does ultimately result in data being changed on Burger, so another part of me says "PUT" or "POST."

What do you think?

Answer 1

I'd opt for a POST because:

• it does change state in BurgerShack (I don't think it's idempotent, because it triggers the GETs from BurgerShack to ChickenShack)
• it does not create a new resource at that specific URL (which rules out PUT)