Exposes the createRESTStore factory, returning an immutable store that forwards every
Store call to a remote REST endpoint. Callers see the same Store surface as every other connector,
with each operation round-tripped to the service rather than applied to a local backing store.
Each HTTP verb is shared by a conditional and an unconditional method, disambiguated through the RFC 7240
Prefer request header:
Conditional (update via PUT, delete via DELETE)
send bare
requests, so the server rejects a missing target with 404.
Unconditional (insert via PUT, remove via DELETE)
send
Prefer: handling=lenient, so a PUT against a missing resource becomes an upsert and a DELETE against one
succeeds silently.
Servers that ignore the header degrade to the conditional 404 behaviour.
Beyond the per-operation miss codes tabulated above, every other failure surfaces as a
Problem rejection: non-OK responses as well as protocol anomalies on
otherwise-successful responses (a missing Location header, a malformed response body). Callers therefore observe
a single rejection type for all error origins.
create resolves the returned Location against the request entry per RFC 3986 § 5.2
and
returns it verbatim, including across origins: the proxy applies no same-origin or path-containment check, so
callers MUST trust the service's choice of child IRI. Standard merge semantics apply, so an entry without a
trailing / strips its last path segment before merging. An unparseable Location surfaces as a RangeError
rather than a Problem.
lookup encodes its model as a URL-safe base64 query string, so any template (filter
operators such as ~name and >=price, nested shapes, aggregates) survives transport intact; an empty template
omits the query string.
Important
entry parameters MUST be bare absolute IRIs with no query string (?…) or fragment (#…): a query string
would collide with the base64 template appended by lookup, and a fragment would be
stripped
by fetch before the request reached the wire. The wrapping
createValidatingStore rejects non-conforming entries with a
RangeError on every method.
The wrapping createValidatingStore validates inputs
(model on lookup, state on every mutation) against the shape before the network
call. Because the remote endpoint is untrusted, lookup responses are re-validated
locally against the shape narrowed by the caller's model. Failures reject with a
TraceError carrying "invalid model", "invalid state", or
"invalid response", per the unified Store error channel.
REST/JSON proxy connector.
Exposes the createRESTStore factory, returning an immutable store that forwards every Store call to a remote REST endpoint. Callers see the same Store surface as every other connector, with each operation round-tripped to the service rather than applied to a local backing store.
PreferGET404→undefinedmodel, responsePOSTLocationheader;409→undefinedstatePUT404→undefinedstateDELETE404→undefinedPUThandling=lenientstateDELETEhandling=lenient404silently ignoredEach HTTP verb is shared by a conditional and an unconditional method, disambiguated through the RFC 7240
Preferrequest header:PUT, delete viaDELETE) send bare requests, so the server rejects a missing target with404.PUT, remove viaDELETE) sendPrefer: handling=lenient, so aPUTagainst a missing resource becomes an upsert and aDELETEagainst one succeeds silently.Servers that ignore the header degrade to the conditional
404behaviour.Beyond the per-operation miss codes tabulated above, every other failure surfaces as a Problem rejection: non-OK responses as well as protocol anomalies on otherwise-successful responses (a missing
Locationheader, a malformed response body). Callers therefore observe a single rejection type for all error origins.create resolves the returned
Locationagainst the requestentryper RFC 3986 § 5.2 and returns it verbatim, including across origins: the proxy applies no same-origin or path-containment check, so callers MUST trust the service's choice of child IRI. Standard merge semantics apply, so anentrywithout a trailing/strips its last path segment before merging. An unparseableLocationsurfaces as aRangeErrorrather than a Problem.lookup encodes its
modelas a URL-safe base64 query string, so any template (filter operators such as~nameand>=price, nested shapes, aggregates) survives transport intact; an empty template omits the query string.entryparameters MUST be bare absolute IRIs with no query string (?…) or fragment (#…): a query string would collide with the base64 template appended by lookup, and a fragment would be stripped byfetchbefore the request reached the wire. The wrapping createValidatingStore rejects non-conforming entries with aRangeErroron every method.The wrapping createValidatingStore validates inputs (
modelon lookup,stateon every mutation) against the shape before the network call. Because the remote endpoint is untrusted, lookup responses are re-validated locally against the shape narrowed by the caller'smodel. Failures reject with a TraceError carrying"invalid model","invalid state", or"invalid response", per the unified Store error channel.See