Warehouse REST API - use ETag header to prevent redundent rereads.

[Brian Lewis]

the warehouse rebuild will now log a serial number for the warehouse build, and the datetime of the build to a new table warehouse.VersionInfo.

Any read to the warehouse API will return this serial number ( actually a guid) value as the ETag header on the response.

Running Pacific EMIS under Chrome will send this value back in an If-None-Match header on any subsequent read to the same Url.

If the warehouse has not been generated since the first read, the warehouse version is unchanged, and the API responds with an empty response with status 304 (Not modified)

This can save considerable data traffic.

[Brian Lewis]

Sample: school dashboard:

Reading for a given school for the first time: get 200 status and data returned

enrolbyschool and enrol/district/r return the ETag:

Read a different school : this time enrol/district/ sends the ETag as If-None-Match header ( Chrome manages this)

Note also the X-Json-Deflate header is present ( see issue #586)

Because the server’s warehouse version matches the If-None-Match header, the server returns 304 Not Modified.

Chrome returns to the application the data previously read - this is transparent to the client-side javascript code.

We return to the first school; this time 2 reads are returned unmodified:

Now refresh the warehouse so that the key changes: this time, the data is reread and returned along with the new eTag:

[Brian Lewis]

feat(warehouse): more flexible REST API; support for ETag

Resolves #665, #666

→ <<cset 83a195db0873>>