this post was submitted on 20 Nov 2024
48 points (94.4% liked)
Programming
17488 readers
107 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Honestly this is completely ridiculous. Hypertext using HTML constraints is absolutely insufficient for representing application state. It's the wrong tool for the job and always has been, because it conflates document structure with semantic meaning.
Said another way, HTML cannot be relied on to capture a representation of application state.
The reason REST doesn't use HTML in most contexts is because applications don't use HTML in most contexts anymore.
Demanding that application representation use a specific encoding strategy is ridiculous and misses the point entirely, which is that HTTP is no longer the right protocol for the job.
While HTML is hypertext markup language, hypertext is not HTML.
Hypertext doesn’t imply a specific encoding strategy, it implies semantics - data contains links to related data. If you want to encode it in protobufs - you do you, REST explicitly calls for freedom in this regard.
To paraphrase yourself, ranting about HTML as if it was a requirement for REST is ridiculous and misses the point entirely.
PS: HTML is not a protocol.
They're not demanding anything. They're describing how the current meaning of REST is nothing like the original one.
They're making a point for not splitting application state and logic into client and server with shared knowledge. If you're making that a pretext of course their argumentation won't fit. They're describing an alternative architecture and approach. Not an alternative protocol for the current common web application architectures.