Having a specification that tells you exactly how to do a particular thing can be more expedient than being open to interpretation. But short-term benefits aren

Having a specification that tells you exactly how to do a particular thing can be more expedient than being open to interpretation. But short-term benefits aren't exactly a goal of REST: >REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release. [0] There isn't anything about REST that is opposed to flexible querying or fetching multiple resources in one request. Isn't that what web pages do already? I've used very complicated search forms and fetched lots of related data on the same page. What makes it possible is the use of standards like query strings, x-www-urlformencoded, multipart/formdata, and HTML itself. Machine clients may just need their own media types. [0] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724 http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...