It
is certainly possible that your particular case is a special one. Certain application
domains just do not fit well into the REST paradigm. (REST has been described as
???Turing-complete??? in a parallel with programming languages. Though any application
may be expressed in terms of REST, some may be much more conducive to
REST than others.) But trying to push yourself into the REST paradigm forces you to
defend any exceptions and special cases, and in doing so you may find that the
exceptions were not necessary after all.
Caching and Scalability
REST fits perfectly with the Rails shared-nothing philosophy??”the idea that the only
communication between application servers should be through the database (in
REST terms, by ???modifying resource state???). We mentioned previously how this
assists scalability; the fewer interactions necessary between application servers, the
easier it is to scale them horizontally when load dictates.
Caching is well known as a hard problem. Phil Karlton famously called cache invalidation
one of the ???two hard things in Computer Science.??? One of the requirements
of HTTPcaching is transparency; the semantics of the information transferred must
Benefits of a RESTful Architecture | 207
be the same as if no cache were involved. What this means in practice depends not
only on what type of caches are used and where they are placed within a network
architecture, but also on the semantics of updates and ???freshness??? within the application
itself.
Pages:
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324