22
The Deprecation HTTP Header Field (greenbytes.de)
submitted 4 months ago by lysdexic@programming.dev to c/programming@programming.dev
15 comments fedilink hide all child comments
all 16 comments
sorted by: hot top controversial new old
[-] domi@lemmy.secnd.me 9 points 4 months ago* (last edited 4 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.

[-] Kissaki@programming.dev 3 points 4 months ago* (last edited 4 months ago)

It makes sense to include so it's obvious in the readable HTTP request response. We use readable URLs and header names for the same purpose: So it is inspectable and understandable from that text format. You may leave deprecation information out, but then you're missing part of the resource description that you're addressing with the URL/URI.

Given a defined header it also allows you to add tooling and automation. There's no need for manual reading.

[-] lysdexic@programming.dev 3 points 4 months ago* (last edited 4 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 1 points 4 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.

[-] NotationalSymmetry@ani.social 2 points 4 months ago

You can simply log this response. Then developers know to replace that call in the next version. If you have unit tests that look for this then you can be sure that your next version is not using any deprecated API calls.

[-] domi@lemmy.secnd.me 3 points 4 months ago

We don't have many unit tests that test against live APIs, most use mock APIs for testing.

The only use for this header would be if somebody sees it during development, at which point it would already be in the documentation or if you explicitly add a feature to look if the header is present. Which I don't see happening any time soon since we get mailed about deprecations as well.

[-] BB_C@programming.dev 5 points 4 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.dev 6 points 4 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 0 points 4 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.dev 1 points 3 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 -1 points 3 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.

[-] lmaydev@lemmy.world 1 points 3 months ago

A certain world event being a 3rd party piece of software having a bad update.

[-] lysdexic@programming.dev 1 points 3 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.

[-] Kissaki@programming.dev 1 points 4 months 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 points 4 months 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.

this post was submitted on 09 Jul 2024
22 points (100.0% liked)

Programming

17314 readers
346 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz