RR is the precursor for cacheability (!)
trades-off efficiency of interaction for easier of integration and better independent evolvability of resources
In a nutshell document-centric means that the message contains enough information to represent a complete unit of work. RPC calls tend to be geared toward sending just the parameters needed to perform the action and have some stateful expectations from the service. Document-centric message, on the other hand, don’t make these assumptions, having a complete unit-of-work, means that the service has enough information or context in the message to understand all the state it needs. This also means that document centric messages are usually more coarse grained compared with their RPC counterparts. Table 5.2 below demonstrates 3 ways document centric messages can contain more context. Context Explanation History The message can contain the interaction up to this point - sort of like breadcrumbs in ht Hansel and Gretel tale. For instance in an Ordering scenario, if the first step was to get customer data and the current step is to set the order (each step can be with another service) the message would contain the customer information when it goes into the ordering service. Future The message can include the options the consumer can take to complete the interaction. Again, if we think about an ordering scenario, if the previous step was to reserve the order (see Reservation pattern in chapter 6), the return message can include the information needed to confirm the reservation. Complete Future Another way to provide context is for the message format to contain the complete details needed for the interaction. For the ordering example, this would mean that the message would have a skeleton to support all the order and related details and the parties involved will fill in the blanks as the interaction progresses.
(contrast this to objects that encapsulate them)
where you can actually find the thing or rather Representations of it e.g.in this case ( www.uri.com.hk ) representations of underwear fashion
HTTP defined a protocol (headers, verbs + response type etc.) GET PUT POST DELETE OPTIONS HEAD (TRACE –loop back the request as it is received by the server, can be a security hazard) CONNECT – defined in the spec as reserved)
e.g. Waka by Roy Fielding with things like Render ~ Get Monitor – subscribe to changes
In UPDATE you can send only the “diff” using put (and the document centric messaging) you can only replace
Can be used to check if state changed since last time if retrieving the body is a heavy operation
e.g. when you call the root URI it will let you know
Easier integration It isn’t that integration magically happen because of the uniform interface – but it is easier for humans to understand In RESTful HTTP integration is even easier because HTTP is ubiquitous so it is also easy to integrate cross-platform Not without challenges e.g. – getting security right, getting URIs right
We already seen that
As mentioned REST trades-off efficiency for interoperability and integration When you do need efficiency then REST is wrong It was also designed for Hypermedia systems (i.e. Web) if your solutions can’t support that, than it is wrong. If you have to integrate existing stuff that is not RESTful than it is wrong Etc.
A lot of people don’t understand REST and can create havoc just like in RPC based system e.g. translating every verb into a URI: http://www.example.com/DoAction The fallacies of distributed computing still matter REST does encourage some of the recommended practices (e.g. statelessness of communications, document centric messages, use of cache etc.)
It builds on simple concepts But you should be mindful to get it right Define the correct Resources Use cache (e.g. ETAG and Last-Modified in HTTP) Parse data in and out etc
Give it a REST already Arnon Rotem-Gal-Oz VP R&D xsights www.xsights.com www.rgoarchitects.com/nblog