• Domi@lemmy.secnd.me
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    2 months ago

    I don’t really get the purpose of a header like this, who is supposed to check it? It’s not like developers casually check the headers returned by an API every week.

    Write them a mail if you see deprecated functions being used by a certain API key, probably much more likely to reach somebody that way.

    Also, TIL that the IETF deprecated the X- prefix more than 10 years ago. Seems like that one didn’t pan out.

    • lysdexic@programming.devOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      2 months ago

      Also, TIL that the IETF deprecated the X- prefix more than 10 years ago. Seems like that one didn’t pan out.

      Can you elaborate on that? The X- prefix is supposedly only a recommendation, and intended to be used in non-standard, custom, ah-hoc request headers to avoid naming conflicts.

      Taken from https://datatracker.ietf.org/doc/html/rfc6648

      In short, although in theory the “X-” convention was a good way to avoid collisions (and attendant interoperability problems) between standardized parameters and unstandardized parameters, in practice the benefits have been outweighed by the costs associated with the leakage of unstandardized parameters into the standards space.

      I still work on software that extendively uses X- headers.

      • Domi@lemmy.secnd.me
        link
        fedilink
        arrow-up
        0
        ·
        2 months ago

        The RFC you linked recommends that no new X- prefixed headers should be used.

        The paragraph you quoted does not say you should use the X- prefix, only comments on how it was used.

        See section 3 for the creation of new parameters: https://datatracker.ietf.org/doc/html/rfc6648#section-3

        I still work on software that extendively uses X- headers.

        I wouldn’t worry too much about it. The reason they give is mostly that it is annoying if a X- header suddenly becomes standardized and you end up having to support X-Something and Something. Most likely a non-issue with real custom headers.

  • BB_C@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    2 months 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.devOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      2 months 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
        link
        fedilink
        arrow-up
        0
        arrow-down
        1
        ·
        2 months 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.devOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 months 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
            link
            fedilink
            arrow-up
            1
            arrow-down
            2
            ·
            2 months 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.devOP
              link
              fedilink
              English
              arrow-up
              1
              ·
              2 months 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.