To some point, I agree! I also used to be a REST purist, but I&#x27;ve become more pragmatic in recent years.<p>Some crucial points that are often preserved even in today&#x27;s API&#x27;s that distinguish them from RPC:<p>- Any REST API will have the concept of resources that are acted upon by HTTP verbs (methods), instead of RPC-style calling a method named in the URI.<p>- statelessness (no session state assumed on the server)<p>- use of HTTP status codes<p>- resource path generally indicates hierarchy or at least a specific &#x27;one path to this representation&#x27;<p>- broad use of existing HTTP headers for metadata instead of a separate &quot;envelope&quot; in the body as in SOAP<p>- use of common HTTP headers such as Authorization rather than cookies or other carriers of state<p>Many of the other compromises are not always because of ignorances, but in order to be broadly useful in the most common cases.<p>I don&#x27;t disagree with your point about not calling it REST, because this trend does diverge from Dr. Fielding&#x27;s dissertation in several important areas (for example, content negotiation, as you point out). That&#x27;s why I prefer the term &quot;loose REST&quot;.