Support for Content-Warnings present as links

[subukris]

In addition to embedded warnings can we support warning links returned instead in headers?

I see at least two advantages with this:

1. It will not mix warning with the response thus allowing response schema validation to work without problems. (Separation of concerns)
2. It will be efficient in terms of network bandwidth usage because the actual warnings payload will be only fetched by clients which intend to use it.

The cons are that it will take additional calls and server has to enable warnings as a resource.

In fact most warnings point the generic nature of the problem so we could have a few links for each type of warning and keep returning the same.

For ex.

Content-Warning: "warning-link"; 1590190500; "https://example.com/warnings/city_unknown"

If the client is interested in doing something about the warning, it can do a GET on it.

GET https://example.com/warnings/city_unknown

and the response will have more details.

     "detail": "City for this zipcode unknown. Code for shipment..",
     "title": "City for zipcode unknown.",

Note that the instance information is omitted from the response because server is stateless. However this is not a problem for the client because it exactly knows the request context for which the warning was issued. Note that it may be possible to cache the warning response by using headers which will avoid redundant requests to server.

[Flix6x]

Could it be preferable to support this use case by registering a Content-Warning Link Relation Type instead? That is, by following Section 4.2 of [RFC8288] to introduce Relation Name: content-warning, you may be able to support your example with the following header:

Link: <https://example.com/warnings/city_unknown>;rel="content-warning";type="application/json"