Web Things, by Mark Baker

Eric Roch comments on a post from Anne Manes from a couple of months ago, and seems to be under some misconceptions about REST.

Misconception: “Stateless” means no persistent data

To be RESTful state must be transferred from the server with each interaction. This can be problematic for many applications – can you trust the other party to maintain state from a security and transactional perspective? For example, if the application keeps a running calculation of product costs – is it okay to transfer the calculated costs and trust the cost when it comes back in the state transfer? Some costing applications are complex and recalculating costs every time the user responses just to be RESTful might not make sense.

This is a very common misconception for REST newbies. What Eric’s doing there is confusing application state and resource state. REST’s stateless constraint only requires that application state be maintained on the client. It places no constraints on resource state, such as Eric’s “running total” above.

Obviously REST wouldn’t be very interesting if it were unable to support persistent data.

Misconception: REST doesn’t support dynamically generated content

Also, since you need unique URIs for caching, you cannot have one URI for a dynamically built page and be RESTful.

That one, I’ve never heard before 8-) It’s not true of course, because dereferencing a URI one day can return a different representation than it does the next day. That’s pretty fundamental to REST.

No wonder Eric’s been such a strong Web services supporter if he thinks REST can’t support changing data, nor persistent state! 8-O

Misconception: HTTP(S) can’t do what I need, so I can’t use REST

Then there are of course the constraints of the HTTP(S) transport […]

Sure, but they have nothing to do with REST. Just because HTTP(S) can’t address your needs, it doesn’t mean you have to abandon REST. You might consider an HTTP extension if you would otherwise be able to use it, but if HTTP is totally out of the question and you need a new protocol, you can still use REST’s constraints in designing that protocol. I’ve done that myself in fact, and designed a UDP based transfer protocol for use over satellite links.