[scottrblock]

I'm afraid this won't be useful in the real world. API consumers who continue to use legacy endpoints after being told not to are unlikely to update their code to listen to a new HTTP header. This strikes me as a great idea in theory, but unlikely to be useful to websites actually looking to deprecate endpoints.

[derefr]

I don’t think this is intended to be about endpoints, but rather about the resources under an endpoint. E.g., “this image will be deleted from this image-hosting service in 30 days” or “this is a link to an item in your Dropbox Trash folder, and the Trash is emptied every 48 hours” or even “this is a temporary share link and will work for 24 hours.”

Given these use-cases, I could also see the use of a version of the header that doesn’t specify when the retirement of the resource will happen, but just specifies that the resource is, by design, not going to stick around forever. E.g. the URL of a “previous version” of something, where the system only keeps around N previous versions (so as soon as someone adds enough newer versions, the version you’ve linked to will disappear.)

Another fun use-case is sticking this header on everything on a given domain (by e.g. reconfiguring your web load-balancer to emit the header.) Archive.org could then use this as a signal to automatically prioritize archiving content from the domain, before any human being realizes the service is being retired and prioritizes that archiving.