Acceptable rate use / significance of "expires" response header

[PJM-117]

To whom it may concern:

HTTP GET requests to api.weather.gov/alerts/active return a "expires" response header which is usually 30 - 45 seconds in the future.

Is this a significant value which actually takes the maximum of active advisories' "Product Expiration Time" (NWS Directive 10-1701 § 3.9.2), or is it a random refresh interval?

Is it acceptable use for our ingest script, running on a single server, to poll this endpoint as fast as the next "expires" interval? If not, is there more concrete information about rate limit compliance? We wouldn't need faster than this, but it appears the preferred method of letting "expires" response header dictate next request would lead to an average cadence of about 30 seconds, which I want to ensure is acceptable for a single 24/7 server to poll.

We are developing a real-time service and already have NWWS integrated, but we love the highly refined parsing that api.weather.gov offers, and seek to implement a dual-source solution. By having 1-3 centralized servers polling/ingesting NWS resources we seek to reduce overall system efficiency by eliminating direct weather.gov access in our client apps.

Kind regards

[dwhitemv25]

NWS API uses a caching layer and re-requesting data before the 'expires' time will simply return the same data you already have. The expiration time is set per endpoint (i.e., forecasts have a longer expires time than alerts). The time may change depending on how many requests there are for the same endpoint/URL in your area.

The exact rate limits are unpublished, but are generally liberal enough to handle the majority of use cases. Once or twice a minute isn't going to run into any issues.

Product expiration time (from CAP data or the WMO header) is unrelated. It would have to be attached to a specific issuance of a specific product, and would also get tripped up by corrections.

[PJM-117]

Thanks for confirming that one or twice a minute HTTP GET requests to /alerts/active shouldn't cause an issue. That is what scheduling the next request on the "expires" field will result in.

So, if it's not based on contained product expiration times, do you know what the actual meaning/process of determination is for the weather.gov API "expires" timestamp response HTTP header from /alerts/active?

[dwhitemv25]

Best I've been able to tell is that the cache-control header directives are set per endpoint. /alerts/active max-age is 30 seconds while /gridpoints/../forecast is 1 hour. The actual expires time served is dependent on when the page content was last cached. The cache-control header is described on MDN.