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.
  • BB_C@programming.dev
    83·
    24 days ago

    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.

    • lysdexic@programming.devOPEnglish
      6·
      24 days ago

      Bloating HTTP and its implementations for REST-specific use-cases

      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.

      • BB_C@programming.dev
        22·
        24 days ago

        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.

        • lysdexic@programming.devOPEnglish
          1·
          15 days ago

          Proper HTTP implementations in proper languages utilize header-name enums for strict checking/matching (…)

          I don’t know what you are talking about.

          Java provides java.lang.Object.HttpHeaders, which is a constants class that provides static final String fields for the popular request and response headers.

          .NET does the exact same thing with it’s class Microsoft.Net.Http.Headers.HeaderNames.

          I can go on and on.

          • BB_C@programming.dev
            12·
            15 days ago

            You just referenced two languages that don’t have proper sum types. lol.

            Also mentioning Microsoft tech while a certain world event is taking place right now. lol.

            • lysdexic@programming.devOPEnglish
              1·
              15 days ago

              You just referenced two languages that don’t have proper sum types. lol.

              You’re complained about “Proper HTTP implementations in proper languages”.

              I provided two concrete examples of two of the most popular and production-grade programming language ever developed.

              I can provide more.

              You then tried to weasel out by moving your goal post from “Proper HTTP implementations in proper languages” to “languages that don’t have proper sum types”.

              I won’t waste more of my time with you. Whatever you’re posting lacks relevance and does not justify any attention from anyone.

    • Kissaki@programming.devEnglish
      1·
      24 days ago

      You’re saying wrong solution but point to the right solution in the same standard?

      • Description: Zapier uses two custom HTTP header fields named X- API-Deprecation-Date and X-API-Deprecation-Info

      Is your issue with the field name only? Why do you say wrong solution then?

      • BB_C@programming.dev
        1·
        24 days ago

        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.