what level of visibility do you really need?
my buddy subbu (@sallamar) said something to me yesterday that lit a bulb above my head:
In REST, the line between a purist and a pragmatist is "visibility". Everything else is implementation detail.
this is a powerful statement
think about all the 'hard' items in REST:
- Partial Upates
- Composite Resources
- Copy, Move, Merge
- Batch
- Transactions
they all impinge on the 'visibility' of the activity. can intermediates (caching servers, accelerators, proxies, etc.) 'see' the activity? think of box-car batches, updating only part of a resource, copying an entire resources tree in a single request, attempting to execute an atomic transaction across more than one server namespace.
now think of versioning, service discovery, custom media types, etc. all these issues mess with the visibility (among other things) of the activity; they hide parts, leave out important meta data, fail to inform caching proxies of changes, and so forth.
that's why some REST 'purists' say these things should not be done. they cause too many problems w/ visiblity, leave things unfinished, out-dated, and broken.
pragmatists, on the other hand, want to weigh the benefits of more efficient handling of requests with the downside of losing some level of visibility.
what level of visibility do you really need?
are you working on the public Internet? within a cloistered private enterprise? do you own both the client code and the server code? are you depending on common browsers?
if you can confidently answer the question "what level of visibility do i really need?" you are a good part of the way toward building a pragmatic, successful RESTful implementation.