Left TBD behind in Flow spec is resolved. Corresponding updates to Repository spec. Is this an adequate resolution? Yes. Note on cache - could just be a proxy pass through, 300-level response.
Service level description at top of Gateway API. JSON for describing.
PUT object has new request header specifying which storage classes/DDPs to post to. Resolves note at bottom. Storage class terminology comes out of AWS. Note that naming should be discussed later.
Versioning
Use case number 2. Repository to Gateway: this involves a number of PUT object requests.
In order to support this use case, the Gateway has to be able to accept a version parameter from the Repo. Need to pass that parameter to the Bridge and roundtrip it. Version parameter has to be semantical to reconstruct if Repo is lost.
Starting point: add version header to requests, see how that looks
Version header content semantics: ordinal numbers, date/timestamps. Date/timestamps follow other standards - Momento. Decision: date/timestamps.
Expectations on PUT header call from the repository to the Gateway uses timestamp. Don't pass a version? Is version required on all PUTS?
Restore request - get whatever's cached vs getting the latest version back.
Symmetrical headers across the board solve the problem. Assume exact matching.
List versions in place. Versions are understandable - IDs of filegroups and timestamps are understandable from Gateway and Bridge. "Give me a listing of all objects and all versions of those objects for a given repository."
