> I see the point that REST is not perfect, but better than "awful". :+1 and they are also better than what author advocates. One thing in author proposal that

> I see the point that REST is not perfect, but better than "awful". :+1 and they are also better than what author advocates. One thing in author proposal that absolutely puts me off is this: > JSON-Pure APIs (...) have only one response code to confirm proper receipt of a message - typically 200 OK for HTTP. This is terrible. PLEASE do not design your API-s like this, this will confuse the hell out of all bots, browsers and everyone who depend on status codes (and that's all web clients). Your 404 error pages will be cached and stored in google, redirects will not be remembered, error pages not retried, etc etc. I don't get the idea of json pure. Author claims that one benefit is: > All errors, warnings, and data are placed in the JSON response payload. But REST-ful API doesn't forbid you from returning informative error messages in json. Why not keep old HTTP semantics known by everyone and return json with informative error message? I also think that author confuses HTTP semantics as defined in actual WEB STANDARDS with purely academic work of Roy Fielding. Meaning of status codes or methods has nothing to do with REST-ful this is just plain HTTP semantics as defined by RFC-s.