I would think this is orthogonal to REST-vs-RPC: > the presumption that GET is safe for [reads] GET requests are supposed to be idempotent and side-effect fre

I would think this is orthogonal to REST-vs-RPC: > the presumption that GET is safe for [reads] GET requests are supposed to be idempotent and side-effect free. Sadly, too often, they are not. Internal state gets mutated, a query parameter gets stored and/or processed in a way that affects future reads, and so on. But then again, nothing prevents you from writing RPC based service with those semantics either. It just might be that people who develop and maintain RPC services are better aware of the consequences of their actions. REST is conceptually easy, has human-readable on-the-wire payloads and operates on synchronous semantics.[×] The bar for entry is simply lower, allowing even an inexperienced developer to get going with very little friction. The very fact that I can do this: import json, requests dada = json.loads(whatever) res = requests.post(URL, data=dada) ... means it's incredibly easy to get off the ground and shuffle data between services. Conversely, it's also easy to send the wrong data, in a wrong way. ×: webhooks are effectively callbacks, but instead of setting the code entry point for async return in your call, you expose a webhook route and treat it as any other request.