> But if your > > application _does_ obey REST principles (which is what is implied by > > "doing REST"), then, yes, it surely does exhibit the properties stated > > earlier. > > No... it MIGHT exhibit them. You can obey the principles of REST and > still create a pig.
Sorry, that's wrong. A system that abides by the constraints enumerated in the REST style will evince the properties associated with that constraint relative to a system that does not. To use the caching example again: There is a fixed cost in running the algorithm that produces a message and there is a fixed cost in transmitting that message over a network. If the algorithm is called twice, those costs are assumed again. If the message is cached, however, the algorithmic costs can be eliminated for future requests (until the cache gets stale) resulting in better performance. Now, one could write a really bad algorithm that runs in time X, and another person can write the same algorithm that runs in time considerably less than X, but the algorithm is outside the scope of REST. All other things being equal a system that employs caching is more performant than one that does not. I have a feeling that you'll jump on the "all other things being equal" bit, but see here: http://en.wikipedia.org/wiki/Ceteris_paribus. How else to analyze and predict the properties of complex systems? > It will also be either completely useless (if there really is no > state) or insecure and unreliable (if all state is retained on the > clients). Statelessness of interaction is one thing, having no state > at all isn't viable (if I place an order I expect you to remember it). The statelessness constraint is _solely_ about session (interaction) state. > A level of statelessness helps in lots of cases, but it doesn't mean > the service is now reliable, just that there are less things to go > wrong (which is a good thing). Exactly! Less things to go wrong means higher reliability. To be fair, and as recognized in the REST dissertation, each constraint comes with a cost as well. For instance, statelessness, as you noted, has a performance penalty in that information that could conceivably be kept on the server now has to be in the message. To handle these conflicts one has to (and Roy did) determine the level of impact that the cost will have on the properties of the system you're trying to bring about. If the cost is negligible, then it can be ignored. If not, then it would be nice to offset it as much as possible. In the case of statelessness, not only does statelessness offer greater reliability but also visibility to external monitoring and scalability, because state no longer has to be kept or managed (or shared) on the server(s). Eliminating statelessness then has serious negative implications. On the other hand the overall performance impact can be mitigated by introducing caching, Since most systems are heavily biased towards reads, the caching constraint more than makes up for what's lost due to the statelessness constraint, resulting in a high-performing system overall. - Pete
