Change Details

We have recently encountered several use cases that - need to `POST` some data to a service, and - would like to store the response of this request at a compact `GET`-accessible location for future use. Examples include: - Graphs: POST from the extension or VisualEditor, GET from the rendered page - Math: POST from the extension or VisualEditor, GET form the reference in the rendered page We might be able to implement this generically: - store the request as a JSON blob in a key-value bucket, using the sha-1 of the JSON - store the response from the backend service in a different bucket, using the same hash - return hash location (in `Content-Location` header?) and original response - alternatively, redirect to `GET` location To facilitate a clean separation between content types, it probably makes sense to use separate request / response buckets per service. By storing the request, we can re-render all requests when necessary. For expiry, we could consider a lazy LRU scheme. In any case, the direct correspondence between request and response key should help with systematic cleanup of both components.

We have recently encountered several use cases that - need to `POST` some data to a service, and - would like to store the response of this request at a compact `GET`-accessible location for future use. Examples include: - Graphs: POST from the extension or VisualEditor, GET from the rendered page - Math: POST from the extension or VisualEditor, GET form the reference in the rendered page We might be able to implement this generically: - store the request as a JSON blob in a key-value bucket, using the sha-1 of the JSON - store the response from the backend service in a different bucket, using the same hash - return hash location (in `Content-Location` header?) and original response - alternatively, redirect to `GET` location To facilitate a clean separation between content types, it probably makes sense to use separate request / response buckets per service. By storing the request, we can re-render all requests when necessary. For expiry, we could consider a lazy LRU scheme. In any case, the direct correspondence between request and response key should help with systematic cleanup of both components. Other considerations: - We might want to limit the sources of POST requests (only authenticated users, by IP) and public read access to the original requests.

We have recently encountered several use cases that - need to `POST` some data to a service, and - would like to store the response of this request at a compact `GET`-accessible location for future use. Examples include: - Graphs: POST from the extension or VisualEditor, GET from the rendered page - Math: POST from the extension or VisualEditor, GET form the reference in the rendered page We might be able to implement this generically: - store the request as a JSON blob in a key-value bucket, using the sha-1 of the JSON - store the response from the backend service in a different bucket, using the same hash - return hash location (in `Content-Location` header?) and original response - alternatively, redirect to `GET` location To facilitate a clean separation between content types, it probably makes sense to use separate request / response buckets per service. By storing the request, we can re-render all requests when necessary. For expiry, we could consider a lazy LRU scheme. In any case, the direct correspondence between request and response key should help with systematic cleanup of both components. Other considerations: - We might want to limit the sources of POST requests (only authenticated users, by IP) and public read access to the original requests.