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