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.