Is anyone up for convincing me that the HTTP accept header is a good idea?
I understand the theory: every resource should have the same URI, and should be able to deliver to clients in the format that they indicate they can best handle - eg an image served as WEBP to supporting clients but falling back to JPEG
But we have 20+ years of real-world experience with it now, and I'm not at all convinced that those theoretical benefits outweigh the drawbacks: mainly its lack of discoverability
I can't remember a time I've ever encountered an API that uses the accept header and thought "oh great, this is going to make my life easier, I'm glad they made that design decision"
I usually think "oh wow, the accept header: that's going to make this less convenient to work with, and I'd better remember that this API uses that or I'll run into all kinds of surprises in the future"
Fedi instances usually use only a single URL for a post. If you request application/ld+json, as ActivityPub spec mandates, you get the ActivityStreams object that corresponds to the post. If you specify nothing or request text/html, you get a web UI for that post.
The advantage here is that regardless of the client you use to view a post (an ordinary browser or an ActivityPub client) the URL the post is identified with is the same.
Of course, we could achieve a similar effect by mandating that the canonical URL return an html page that has a meta tag/header/... that points at the URL where one can retrieve the ActivityStreams object, and vice versa. I would consider that to be much more complicated though.
