specification
specification copied to clipboard
solid
Commitments to requests
There are use cases [citation needed] that require servers to process requests where servers may not want to commit to providing a response before closing the connection.
For example: creating or deleting /foo/bar/baz has both idempotent and non-idempotent side effects. Server that are capable of making decisions based on side effects may want to respond quickly to inform clients about their request.
One way to effectively communicated that is in a response with 202 status.
What level of conformance should be expected of servers and clients to handle 202?
:+1: not sure if i understand the relation with idempotency, but i like how you phrased it with ‘not willing to commit to a response’, implying that best-effort responses are forbidden.
“Best-effort” = possibly incorrect / outdated / to be reverted in a later server-side decision.
I think both kinds of responses can be accommodated. I would consider any response to have an element of "best effort" - at the time the communication took place. Mutable resources encompass a wide range of cases. Responses can always be verified.
All of this seems fine to me. What would be useful for the multi-resource creation case (neither /foo nor /foo/bar exist when a server receives a PUT request for /foo/bar/baz) is simply to state clearly in the specification that a server MUST (or SHOULD? but it seems MUST is appropriate here) also create those parent containers. I could imagine use cases for the 202 Accepted response, but it's not needed at the moment.
I would consider any response to have an element of "best effort"
So I think what you are saying is the server could choose to reply '200 OK' even when really things are not OK. For instance the data it serves might be incorrect or outdated. In other words, clients always need to consider the possibility that the server is buggy. The best practices docs for servers should not say that servers are allowed to be buggy, but the best practices docs for clients should probably say to not always believe what the server states, and to treat any server as a potentially imperfect system.
@acoburn Parent containers are required to be created in the multi-resource creation case.
@michielbdejong I just take it as a given that server knows best and client takes the response status as is.
@csarven as discussed on Gitter,
I just take it as a given that [the spec does not prescribe strong consistency]
Please add a note about that in the documentation for client implementers. Some client implementers might (falsely) assume all spec-compliant Solid servers are strongly consistent, so we need to explain to them that whether or not a Solid server is strongly consistent is orthogonal to whether or not that server is compliant with the Solid spec.
I'll take @michielbdejong 's latest comment as rough consensus, the concrete formulation can be done in the drafting phase.
Let me jot this down hopefully for some clarity:
i like how you phrased it with ‘not willing to commit to a response’, implying that best-effort responses are forbidden.
So I think what you are saying is the server could choose to reply '200 OK' even when really things are not OK
I think the term "best effort" may be misleading. The point I was trying to make wasn't that a server can or should respond with 200 or 202 randomly, but that they know what's going on internally, so naturally choose a response that matches their situation. If all inner operations are successful, 200. If not sure or expecting potential delays or conflicts... 202 is fine.
If all inner operations are successful, 200. If not sure or expecting potential delays or conflicts... 202 is fine.
If by 'successful' you mean 'successful and final', then that's not what we decided. We decided that whether or not a Solid server is strongly consistent is orthogonal to whether or not that server is compliant with the Solid spec. So from now on, a server is allowed to respond with a success response, even if the change has not propagated yet and even if it can still be rejected later.
We're not modifying the definition of 200 and 202. They are both final in the sense that server decided on something and communicates back to the client. End communication. 200 entails that the request went through as a whole - atomic requirements are met. 202 doesn't say much more than just "got your request, will look into it... maybe check over here for the status". Like I said, whatever is expected of the original request that 202 responded to may not succeed because it is "intentionally noncommittal" - an aspect of the request may not be carried out (for whatever reason, including atomicity requirements).
200 entails that the request went through as a whole - atomic requirements are met.
No, because eventual consistency is now allowed. See https://github.com/solid/specification/issues/91#issuecomment-539548997
In light of #91 it does seem like we did not quite reach rough consensus here anyway, so I'll return it to consensus phase.