2 ms·

> You should [...] At least there's no namespacing or DTD's! JSON plus a loose adherence to REST won out over SOAP/XML-RPC/WSDL/etc because of its simplicity.

> You should [...] At least there's no namespacing or DTD's! JSON plus a loose adherence to REST won out over SOAP/XML-RPC/WSDL/etc because of its simplicity. Services discovery seems to be a solution in search of a problem. Even the simple idea of embedded links, with apologies to Dr. Fielding, seem to be a less critical component of REST than was initially believed, since very few modern REST API's actually provide them.

dragonwriter 11y ago
Very few modern "REST" APIs have even a remote resemblance to the REST architecture described by Fielding, it's mostly just RPC over HTML with data in an specialized subset of JSON or XML that is specified per endpoint out-of-band rather than indicated by media type. I really wish people would stop calling it REST, since that Rob's the meaning from the term.
- jamiesonbecker 11y ago
  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".

dragonwriter 11y ago

Very few modern "REST" APIs have even a remote resemblance to the REST architecture described by Fielding, it's mostly just RPC over HTML with data in an specialized subset of JSON or XML that is specified per endpoint out-of-band rather than indicated by media type. I really wish people would stop calling it REST, since that Rob's the meaning from the term.

jamiesonbecker 11y ago
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".