Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What does a read operation imply? #149

Open
csarven opened this issue Feb 20, 2020 · 5 comments
Open

What does a read operation imply? #149

csarven opened this issue Feb 20, 2020 · 5 comments

Comments

@csarven
Copy link
Member

csarven commented Feb 20, 2020

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
Copy link
Member

kjetilk commented Feb 21, 2020

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

@justinwb
Copy link
Member

LGTM 👍

@kjetilk
Copy link
Member

kjetilk commented Feb 21, 2020

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
Copy link
Member Author

csarven commented Feb 21, 2020

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
Copy link
Member

kjetilk commented Feb 22, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Drafting Phase
Development

No branches or pull requests

3 participants