What does a read operation imply?

[csarven]

Definition of the read operation alongside #118 , #126 ..

A read operation entails that information can be revealed about the content of a resource, and categorically excludes operations to "write", as well as unintended exposure or side-effects within that.

[kjetilk]

Yeah, sounds good to me. Great to have for completeness.

[justinwb]

LGTM 👍

[kjetilk]

BTW, we could also say something along the lines of "does not alter the state of the representation of any resource". And then, that might not be completely accurate, because we might have audit log metadata resources that would be appended to on every read, but that is such a corner case it would be OK to say anyway. :-)

[csarven]

I'm glad you're raising this because I thought about that when trying to reuse the write and append descriptions as a guide eg. "A write operation affects a set resources" for the read operation. Decided to leave eg. "A read operation does not affect resources" because I thought it should be aligned with 7231's "safe methods" as much as possible eg. "that is not entirely read-only". Figured the existing proposed "unintended exposure or side-effects within that" would generally cover that ie. from the client's perspective, read triggering a write behind the scenes would be "unintended" I think.

Under normal circumstances, I agree that it should not alter the effective request URI - I think that's the intended resource that shouldn't change as opposed to any resource.

Edit: so, I'm not sure. Adding something like "A read operation does not affect the target resource" seems a bit redundant re 'categorically excludes operations to "write"'

[kjetilk]

Yeah, it sounds a bit redundant. Apart from control, we have three different classes, where append is a restricted case of write, and read and write are non-overlapping, so we should adopt language that makes it clear that these describe all operations exhaustively together, and mutually exclusive each. I like the idea of applying the safe methods and stuff, but also the idea of "state of representation". I think we are pretty align, we can argue over details later.