The Deprecation HTTP response header field is used to signal to consumers of a resource (in the sense of [URI]) that the resource will be or has been deprecated. Additionally, the deprecation link relation can be used to link to a resource that provides additional information about planned or existing deprecation, and possibly ways in which clients can best manage deprecation.
Weak use-case.
Wrong solution (IMHO).
If one must use a header for this, how Zapier or Clearbit do it, as mentioned in appendix A.2, is the way to go.
Bloating HTTP and its implementations for REST-specific use-cases shouldn’t be generally accepted.
I have no idea what are you talking about. Setting a request/response header is not bloating HTTP. That’s like claiming that setting a field in a response body is bloating JSON.
Proper HTTP implementations in proper languages utilize header-name enums for strict checking/matching, and for performance by e.g. skipping unnecessary string allocations, not keeping known strings around, …etc. Every standard header name will have to added as a variant to such enums, and its string representation as a constant/static.
Not sure how you thought that shares equivalency with random JSON field names.
You’re saying wrong solution but point to the right solution in the same standard?
Is your issue with the field name only? Why do you say wrong solution then?
Yeah, sorry. My comment was maybe too curt.
My thoughts are similar to those shared by @Domi in a top comment. If an API user is expected to be wary enough to check for such a header, then they would also be wary enough to check the response of an endpoint dedicated to communicating such deprecation info, or wary enough to notice API requests being redirected to a path indicating deprecation.
I mentioned Zapier or Clearbit as examples of doing it in what I humbly consider the wrong way, but still a way that doesn’t bloat the HTTP standard.