I hope I'm not beating up a straw man here, but I have seen many claim that REST is a good solution that scales well because the web is built on the REST philosophy. The principles of REST are why the web is a success, and so if we use REST, we can attain the same benefits. What you seem to be proposing is that the web is not a good example of REST.<p>If this is the case, is there any good example of REST? I have yet to see a web service API that does not require one to read the docs to do URL construction, which violates the HATEOAS principle. The only examples I know of where HATEOAS is satisfied are HTML forms, as I mentioned, Atom feeds, and OpenSearchDescription. None of these are elaborate APIs (or APIs at all) where one would even need to consider something like XML-RPC.<p>I think HTML forms are a perfect example of REST, since they supply the client with all necessary information to build the next request, and URLs do not need to be constructed manually. The way 302s are used to redirect to the newly-created resource makes web browsers behave more RESTfully, since they prevent reloads from resubmitting POST requests. This is a very common practice today, and I would consider it one of the best examples of REST done right, and yet it uses a different HTTP response code than the proposed standard of 201 Created.<p>All I'm trying to do is show that there are at least two codes, 201 and 302, that properly RESTful services might return, to support my argument that response codes are not uniform across all REST services.