This question already has an answer here:
I have a question regarding HTTP methods and what would be most proper in terms of conforming to REST principles.
I have two services, A and B. When new data is added, or old data is updated at Service A (e.g. POST/PUT) it triggers Service A to contact Service B to let it know that new data is available. Then Service B requests data from Service A via a GET endpoint and caches the response for later use.
What would be a good method of triggering this process to happen in Service B? The process that happens inside Service B goes as follows:
- Receive trigger
- Clear cache
- Request data (GET Service A)
- Cache response
So this process clears the current cached data and then stores new information to the same cache.
I was thinking a HEAD request would be good, as we are not sending any data from Service A, nor expecting any response - just letting Service A know, that it should do something.
I read from somewhere, that a GET/HEAD request should not alter the state of a service, so perhaps this wouldn't exactly comply with REST principles. In this case, would PUT method be more appropriate, because we are updating/renewing the cache? Even though the PUT trigger would have an empty request body?
One suggestion was to use a PUT endpoint at Service B and to just deliver the new data, and have no pull mechanism, but then the PUT endpoint needs some authentication. Using a trigger GET/HEAD method would just let Service B know that it needs to fetch new data. Service A knows the URL of Service B beforehand, and would request data from there, regardless of who activated the trigger, so Service B doesn't use the requestor's URL.
EDIT: For the duplicate suggestion, I suppose the meta-question of this problem is: "Is there a RESTful method to trigger a state change in a web server, without delivering data?" Yes: I wonder what that would be. No: It's not a RESTful web service.