Allow configuration of proper Cache-control headers (for unauthenticated requests)

[tuxpiper]

Which user group(s) are the primary audience for this feature/enhancement.

Specially important for deployers hosting popular deployments

Is your feature request related to a problem? Please describe.

As traffic increases, so does pressure on the API service. Servers may start struggling / may demand resource expenditure beyond what is in the budget for the deployer.

Describe the solution you'd like

HTTP caching is one of the first go-to solutions considered, in order to alleviate load pressure on servers.

Although caching can be leveraged at several points between the server and the user's browser , it all starts by setting proper "Cache-control" headers at the origin. Currently this header is set to: no-cache, private , which marks all API content as not safe to cache.

This issue suggests to allow enabling caching for some unauthenticated requests and possibly allow setting different max-age limits for different classes of endpoints.

Instead of setting the same max-age for all responses, a more granular approach allows to better optimize along the compromise between cost and user experience. Not all API endpoints cause the same pressure on the servers and not all data has the same impact on user experience if it's stale.

In more detail:

• Data aggregation endpoints — these are usually the heaviest on the servers, because they go through all the data stored by the deployment. On the other hand, obtaining data that is somewhat old (usually talking minutes here) may not have a great impact on user experience. Examples: /api/v3/geojson and /api/v3/stats . These are prime candidates to receive the longest max-age configurations.
• Data pagination endpoints — these may be somewhat heavy, because they go through bunches of data at a time. However, depending on how pagination is implemented and how the client application handles paginated results these can have quite negative effects on user experience. This includes behavior usually perceived as buggy, such as presenting lists with repeated or missing entries. Exampes: /api/v3/posts .
• Data item endpoints — these are typically light (single data points) and stale data doesn’t necessarily have great impact on the overall user experience. Examples: /api/v3/posts/:id.
• Metadata items/list endpoints — these are typically light, but very frequently called. Stale data may have great impact on user experience, as usually metadata aids to properly render data or steer application behavior. Examples: /api/v3/tags , /api/v3/forms , /api/v3/config .

At the very minimum, we would suggest allowing enabling HTTP caching for the first type of endpoints, as that’s where the biggest gains are to be obtained with the least risk.

Aha! Link: https://ushahiditeam.aha.io/features/PROD-789