fix(AIP-121): clarify stateless protocol definition

[noahdietz]

Clarifies definition of a stateless protocol as applied to resource oriented APIs after some confusion created by the lack of concrete/applied language.

cc: @Berg3

[bgrant0607]

I think the AIPs follow the usual definition of "stateless protocol". For example:
https://en.wikipedia.org/wiki/Stateless_protocol
https://en.wikipedia.org/wiki/Representational_state_transfer

There's no "session" state.

etag could maybe be called out as a stateful feature.

[noahdietz]

@bgrant0607 was your comment meant to be elicit a specific change? Did you want to see mention of "no 'session' state" in this section? I kind of thought that the following phrase spoke to that point:

each request happens in isolation of other requests made by that client or another

I'm happy to change stuff, but would appreciate a more pointed comment.

etag could maybe be called out as a stateful feature.

Yeah good point, I think I see what you are getting at. A client must have the latest etag (perhaps retrieved via a preceding GET) in order to mutate a resource. So the client and server state must match, effectively a "session". Is that what you are getting at?

I don't think that exactly violates the statement each request happens in isolation of other requests made by that client or another because technically the request, even with an invalid etag, is processed independently of requests made previously, regardless of if the response is an error due to etag mismatch or not. Of course our backends aren't stateless, but the protocol in which we communicate with it is. WDYT? Is that a fair analysis?

[bgrant0607]

@noahdietz I was just commenting that I believe the term "stateless protocol" is used here with its typical meaning. We could link to wikipedia or another source.

[noahdietz]

@noahdietz I was just commenting that I believe the term "stateless protocol" is used here with its typical meaning. We could link to wikipedia or another source.

Oh ok, I see. Indeed a source would be good, too avoid more confusion in the future.

[noahdietz]

Added a link! Thanks for that @bgrant0607

[bgrant0607]

LGTM