> REST was at least spiritually trying to adhere to the ideas of HTTP verbs That's kindof the problem: Except in the case where a thin browser front end is re

> REST was at least spiritually trying to adhere to the ideas of HTTP verbs That's kindof the problem: Except in the case where a thin browser front end is rendering a single response payload transferred by necessity over HTTP a la XSLT (which we're not doing anymore for better or worse) there's absolutely no rational reason to stick to "REST principles" in quasi-religious manner and exegetic interpretation of Fielding's thesis that coined that term. In fact, I'd say it's counterproductive, because a simplistic "REST" facade doesn't even begin to describe the actual interaction between backends or rich frontends and backends, those interactions often being stateful and much more involved and granular than sending back-end-forth idealized full "representations" or flawed over-exposing ideas of the nature of a backend concept. You might think that SOAP-like UpdateOrderLineItemBilling granular ops suck, but these are much more representative and telling than coarse pretentious REST APIs suggesting you could update anything at any point in time during the course of a process, when in reality backend logic just doesn't work that way (eg in the ecommerce example, you'll have to honor the delivery and billing status of items to cancel, and compensate or retour items accordingly, etc). Really, "spiritual programming" isn't an engineering discipline; you can model your backend-to-backend interactions freely without having to appeal to concepts from HTTP taken completely out of context.