Relation between resource representation sent and received

[michielbdejong]

Reading section 5.5 there is a requirement to 'satisfy a GET request', but it's not clear to me what that means exactly.

A resource has a lifecycle that starts with a create, possible followed by linear set of updates, and possibly ended by delete.

I think the Solid Protocol requires servers to 'satisfy GET requests' with a response body that is a best-effort representation (given the request details) of the current, or at least a best-effort recent, state of the resource.

But I'm missing the following statements from the spec:

• each resource has only one current state at any one time
• successful write requests update this state. Servers should make a best effort to follow the instructions received in write requests
• in the absence of successful write requests that affect a resource, the state of that resource should not change
• when satisfying GET requests servers should make a best effort to ensure that the representation of the resource returned in the response body is as close as technically possible to a recent resource state (possibly translated as requested)
• server should make a best effort to respond to read requests based on a resource state that is as recent as possible

Maybe this is intentional, we just want to specify the interaction, not the functionality of a Solid server? In that case it's maybe a bit misleading to talk of 'storage', if what the spec describes is merely an 'interface' without any assumption of resources actually getting stored?

Or maybe I'm not looking in the right place?

[CxRes]

I think all of this follows from RFC9110 HTTP Semantics. See Classes of Products > Server

If something does not, only then does it need to be documented in Solid Protocol.

[michielbdejong]

You're right! RFC9110 sets some quite clear min and max boundaries on expectations. It does seem to imply each resource has only one current state at any one time, PUT and DELETE update it (POST is a little less clear).

For PUT it does mention "the target resource might be acted upon by other user agents in parallel [...] before any subsequent GET is received" but I think that sentence does still assume a unique serialisation of the event log, and also phrases like "past, current, or desired state of a given resource", "the resource state" and "multiple representations that are each intended to reflect the resource's current state" seem to support the linear-event-history assumption, and the 'only one current state' invariant does seem to be maintained. But I didn't find a clear positive statement of 'there can only be one resource state at a time'.

RFC9110 does explicitly allow the server to behave in different ways, other than as a storage. I think it's Solid that introduces the term 'storage', and doesn't clearly define what it means in terms of concurrent versioning.

But maybe that's OK. See also our discussion during the CG call.

[CxRes]

But I didn't find a clear positive statement of 'there can only be one resource state at a time'.

That is implicit in the common understanding of the word "state". Certainly, HTTP does not support super-positions of state. That clients have accessed different representations states and may attempt to act on them is of no concern of the server (This follows from client-stateless-server constraint of REST).

I think I understand the source of the confusion, though. Clients can have accessed representations of different states and act with unsafe methods with the assumption that server is on the said state. But all actions will be applied on the latest state (or not applied at all). Natively, no mechanism exists in HTTP to specify that a server act on a prior state, thus no way of creating non-linear history on the server (such as would be necessitated by certain CRDT/OT algorithms). This would be the prerogative of a versioning extension to HTTP and/or Solid Protocol.