22
The Deprecation HTTP Header Field
(greenbytes.de)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 09 Jul 2024
22 points (100.0% liked)
Programming
17314 readers
332 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
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.
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.
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.
A certain world event being a 3rd party piece of software having a bad update.
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.
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.