"With PUT, the state encapsulated by the incoming representation will wholly replace the state of the resource hosted by the service. This obliges client to PUT all the resource state, including any links,as part of the representation it sends"
a) With some resources, not all state can be set by client, but instead some state can only be set by a service ( to my understanding, state that can only be set by a service can still be included in a resource representation sent to the client ).
But is the above quote suggesting that with PUT, client needs to send/set all resource state, even the state that should only be set by a service?!
b) If quote is indeed suggesting that clients should PUT all the resource state ( including any links ), then why doesn't example in your book have clients also set the link state when paying for order via PUT?
Namely, as seen in example 5-8, payment resource also includes two links as part of its state and according to the above quote, clients paying for order via PUT should also set the state of those two links ( though one could argue that at the time client initiated payment via PUT, the state of resource didn't yet include those two links as part of its state <-- but that's a bit confusing, since that's like saying an instance of a class has a property at certain points of execution, but it doesn't have that property at other points of execution)!
> In the web-as-deployed, partial updates often use the PUT method. In the Web as defined, standardized, and deployed, those partial updates using the PUT method are not interoperable with standard HTTP/1.x servers. That has been known since the idea was first brought up and has not changed since then. We could not make non-compatible changes to an existing method in 1996, nor 1999, nor can we do so now in 2012. There is no such thing as partial updates using PUT.
The problem is that, as the server evolves, older clients won't be able to know what parts of that data it MUST send back and which parts of the data it can ignore. So by building clients that do not send everything back we break (some of) the server's ability to evolve freely and independently of the clients life cycles.
On 8 Apr 2020, at 19:44, Mitch Trainham <mitch.t...@gmail.com> wrote: