Gives an application access to a remote REST service through the standard Store API.
createRESTStore returns a store with the same surface as every other connector. Each data operation is
round-tripped to the service rather than applied to a local backing store.
Each mutating 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 behaviour: insert against a
missing resource then rejects with a 404Problem.
Beyond the per-operation miss codes tabulated above, every remote failure surfaces as a
Problem rejection. This covers non-OK responses as well as protocol anomalies on
otherwise successful responses, such as a missing Location header or a malformed response body. Callers therefore
handle every remote failure through a single rejection type.
create posts only the state of the new resource. The model slice naming the collecting
property is validated locally but not sent, so the service identifies the collection from entry alone.
create resolves the returned Location against the request entry per RFC 3986 § 5.2.
Standard merge semantics apply, so an entry without a trailing / strips its last path segment before merging.
The resolved IRI must lie strictly below the container entry resolves to, that is entry itself when it ends
with / and its parent otherwise: a Location outside that scope, whether on a foreign origin or elsewhere on the
same one, rejects with a Problem, so a misbehaving service can't make the caller
adopt a foreign child IRI. An unparseable Location surfaces as a RangeError rather than a
Problem.
lookup carries its model as a base64url query string, so any template (filter operators
such as ~name and >=price, nested shapes, aggregates, collection pagination) survives transport intact. An
empty template omits the query string. The scope locale is forwarded as an Accept-Language header, with a
trailing * fallback so the service may answer in any language when none of the listed ones is available.
IRIs on the origin of entry travel in root-relative form (/…), both in request templates and states and in
lookup responses. Root-relative references in a response are resolved against the origin of
entry, so the service may return them in place of absolute IRIs. Any other relative reference is rejected by
response validation.
Important
entry parameters MUST be bare absolute IRIs with no query string (?…) or fragment (#…). A query string
would collide with the template carried by lookup, and a fragment would be stripped by
fetch before the request reached the wire. Non-conforming entries are rejected with a
RangeError on every method.
Inputs are validated against the shape before the network call: model on lookup and
create, state on every mutation carrying one. The query-complexity bounds of the
retrieval scope are also enforced locally, so a rejected template never reaches the service.
Because the remote endpoint is untrusted by default, lookup responses are also validated
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.
Gives an application access to a remote REST service through the standard Store API. createRESTStore returns a store with the same surface as every other connector. Each data operation is round-tripped to the service rather than applied to a local backing store.
PreferGET404→undefinedmodel, responsePOSTLocation;409→undefinedmodel,statePUT404→undefinedstateDELETE404→undefinedPUThandling=lenientstateDELETEhandling=lenient404silently ignoredEach mutating 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 behaviour: insert against a missing resource then rejects with a
404Problem.Beyond the per-operation miss codes tabulated above, every remote failure surfaces as a Problem rejection. This covers non-OK responses as well as protocol anomalies on otherwise successful responses, such as a missing
Locationheader or a malformed response body. Callers therefore handle every remote failure through a single rejection type.create posts only the
stateof the new resource. Themodelslice naming the collecting property is validated locally but not sent, so the service identifies the collection fromentryalone.create resolves the returned
Locationagainst the requestentryper RFC 3986 § 5.2. Standard merge semantics apply, so anentrywithout a trailing/strips its last path segment before merging. The resolved IRI must lie strictly below the containerentryresolves to, that isentryitself when it ends with/and its parent otherwise: aLocationoutside that scope, whether on a foreign origin or elsewhere on the same one, rejects with a Problem, so a misbehaving service can't make the caller adopt a foreign child IRI. An unparseableLocationsurfaces as a RangeError rather than a Problem.lookup carries its
modelas a base64url query string, so any template (filter operators such as~nameand>=price, nested shapes, aggregates, collection pagination) survives transport intact. An empty template omits the query string. The scopelocaleis forwarded as anAccept-Languageheader, with a trailing*fallback so the service may answer in any language when none of the listed ones is available.IRIs on the origin of
entrytravel in root-relative form (/…), both in request templates and states and in lookup responses. Root-relative references in a response are resolved against the origin ofentry, so the service may return them in place of absolute IRIs. Any other relative reference is rejected by response validation.entryparameters MUST be bare absolute IRIs with no query string (?…) or fragment (#…). A query string would collide with the template carried by lookup, and a fragment would be stripped by fetch before the request reached the wire. Non-conforming entries are rejected with a RangeError on every method.Inputs are validated against the shape before the network call:
modelon lookup and create,stateon every mutation carrying one. The query-complexity bounds of the retrieval scope are also enforced locally, so a rejected template never reaches the service. Because the remote endpoint is untrusted by default, lookup responses are also validated 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