peerReadRoutes

The read routes of the services' peer reads, served on the internal port beside the call routes (callRoutes): the same paths and answers as the public port's query routes, state reads and dataset routes, for the services that read this one through wow-client's service mode, without the end user's credential.

• POST and GET /{context}/{aggregate}/{model}/query of each query model of the Manifest, 404 for one queries does not serve (never the call routes' unknown command);

• GET /{context}/{aggregate}/{id}/state (?version=, ?at=) of each aggregate, over reads;

• POST and GET /wow/dataset/{context}/{dataset}/query of the datasets queries has;

• GET /wow/manifest, the service's Manifest, for a service that calls it by its Manifest alone (wow.peers.<context>.contract: manifest): any service may read it, whatever models permits list.

Each request must come from a service identity, which callerResolver resolves (the service the request names, me.ahoo.wow.http.caller.DeclaredServices), and carry Wow-Call, the root context it reads for; any other, one that names no service too, is answered 403 wow.auth.forbidden, and so is a model permits does not let the service read (CallPermits.readRefusal). The read then runs as the root context's caller: its tenant (the aggregate type's fixed one, when it has one), its owner and space, its operator as the subject and its application (app_id of the root request's facts) as the caller's app, so the scope policy, the access policies and the application's query policies restrict it as they would the root request's, and it is masked alike. A root no end user sent, one whose operator is a service (service:<name>) or a framework component (system:<component>), reads as that service: a service identity, trusted, which no access policy restricts, bounded by the models permits let the calling service read. The root carries its end user's identity and scope, not the claims the end user's credential holds: an access policy reads such a root's claims as missing, and denies on them. Its command id and causation say nothing here. A Wow-Scope is refused, as for any caller that may not act across scopes. None of these routes is in the OpenAPI document: they are the services' own. The streamed answers are produced in scope, as wowRoutes's are.