Several of these points are highly prescriptive without offering any motivation for the advice.
For example, "your public API should not depend on the structure of your URIs. Instead there would typically be a single XML file that points to the components of your service." It's difficult to understand this kind of point without an example in hand - preferably an example taken from an actual website.
The whole list presupposes a familiarity with REST theory and jargon. And the assertion that 'sessions are irrelevant' instantly raises my suspicions about the author's relationship with reality.
By "sessions are irrelevant", he basically means "don't recreate circuit switching on top of your packet-switched TCP/IP connection." Each HTTP request should carry with it all the state required to do what it needs to do (including state stored in cookies et all); it shouldn't be dependant on what has come before or what will come after it.
Right this is a huge item when it comes to scalability. I argue this with developers all the time. The problem is that session is like Crack, it starts with just a little. It is so easy to get caught up in storing off some info in a property bag or List for later use, but it binds you to so much hardware and software infrastructure, by using just one little pattern.
I am old enough to remember the first time the session pattern was used in a web framework, I remember cringing then just as I do now when I see it used.
I agree. A lot of the more pedantic REST advocates seem to use this kind of thinking, such as implying that we shouldn't use descriptive URIs because the client or programmer shouldn't need to understand how the URIs are structured. If that's the case, surely we could break REST convention as much as we want and just make the programmer or client go along with it.
I think when most normal people say REST, they simply mean some sort of vague messages-over-HTTP metaformat that doesn't necessarily enforce odd restrictions about POST vs. PUT, is somewhat self-documenting and easy to work with due to the limited scope of the medium, etc.
I don't think it was implied that we shouldn't use descriptive URIs—just that descriptive URIs should be treated in roughly the way we treat comments—they're for humans to work with, not computers, unless there is an established microformat (like the various -Doc formats used in comments) that the service can be guaranteed to obey. That microformat would, obviously, be linked to in place of the index XML file—as it would be able to be used to procedurally generate same.
I agree too. Roy Fielding's dissertation on REST does say that URIs should not contain information about the identity of the user nor the details of the implementation of the resource on the server (no .php, .cgi, .aspx) but in a section on URIs (6.2.1) he does say "...REST accomplishes this by defining a resource to be the semantics of what the author intends to identify..." I read that as a requirement for descriptive URLs.
And I think of Fielding's dissertation, together with a few RFCs like 2616, as the founding documents of REST.
tlack,
when you write 'A lot of the more pedantic REST advocates' you make it seem as if there was a choice to be 'strict REST' or 'less pedantic REST'. The problem with that is as follows: REST is an architectural style, which means that it consists of a set of constraints it imposes on an architecture. The benefit is that such constraints induce a set of system properties (e.g. cacheability, scalability). Usually, the choice for an architecture means that you are interested in your system having these properties.
Now, if you drop constraints at will, you modify the style and do not get the desired system properties.
The notion of 'non pedantic REST' (or 'Low REST') is missing the point.
the idea is that instead of documenting your project list to be at /projects/ and individual projects to be at /projects/PROJECT_ID you should have a SINGLE entry point into your API which should have LINKS to your various services.
and then your project list should not just return you projects ids to construct a url with, instead it should provide you full urls to access the relevant resources.
The rule of thumb is: with a PROPER REST API you should never do any "url generation", you should get ALL your urls (except for the SINGLE entry one) form the API.
For example, "your public API should not depend on the structure of your URIs. Instead there would typically be a single XML file that points to the components of your service." It's difficult to understand this kind of point without an example in hand - preferably an example taken from an actual website.
The whole list presupposes a familiarity with REST theory and jargon. And the assertion that 'sessions are irrelevant' instantly raises my suspicions about the author's relationship with reality.