I was introduced to RESTful APIs when Rails started championing them. And while I've read a number of REST articles, it still seems like I'm not understanding

I was introduced to RESTful APIs when Rails started championing them. And while I've read a number of REST articles, it still seems like I'm not understanding the nuances of long-term vs short-term decoupling of client/server to the level that Fielding demands for REST. For example, there's his blog entry here: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... A key point is this paragraph: "A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]" --- When I try to absorb this and other points in that blog entry, I feel like I've failed to understand the real lessons and I'm thinking too short-term with fixed URIs for CRUD on data. But then again, in the comments, Fielding says "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." This makes a lot of sense to me and suggests that truly RESTful design isn't necessarily the best fit for people who want to throw stuff up on the web and then evolve to a more stable API.