Proposed New Feature: Add Caching Capabilities

[mkaplun]

Add the capability to cache SDS responses.
Caching infrequently updated but often voluminous responses by SDS will considerably reduce bandwidth, latency, and load on servers and hide network failures.
A registry associated with an SDS instance may generate and store a "fresh" version of the response each time its content is updated.
Therefore, consistently with REST recommendations, GET requests should/can be cached by default - unless a client asks otherwise.
The handling of a POST request should be evaluated in conjunction with Issue faa-swim/sds20#4.

[wznira]

To support caching, optional parameters should be included in the requests and responses to indicate the required/actual timeliness of the data.

For example, a client may indicate that it is willing to accept a cached list of published services as a response to its GetServices request only if the list is created less than 12 hours ago. There are several operations to accomplish this, for example -

1. Using a cache control HTTP header to indicate that a cached response is acceptable or not, for example -
   • HTTP Header: Cache-Control: max-age = 43200
   • HTTP Header: Cache-Control: no-cache
2. Include a query parameter in the request - /sds/services?max-age=43200

Similar, a DS may include a timestamp for the information it returns. For example,

1. It could include a lastModified property in its JSON response to indicate the timeliness of the data
2. It may use an Age HTTP header.

[mkaplun]

I think there are several scenarios to consider in establishing caching in SDS.

Scenario 1. As suggested by @wznira in his comment. (However, Cache-control directives may require further research and potentially be extended.)

Scenario 2. To incorporate requirements or best practices into SDS documentation requiring SDS owners to update their caches when changes occur. For example, adding a new service to a registry should trigger updating the associated cache. SDS owners should also follow a similar approach when learning about new peers.
This way, infrequently changed information (e.g., list of peers, list of services) stays "fresh" and decreases the service's response time significantly.

Scenario 3. Some combination of 1 and 2. Even though the best effort should be made to ensure that a "fresh" cache is readily available (scenario 2), caching may still be controlled using Cache-control directives (scenario 1).