[HN Gopher] Why I tend not to use content negotiation
___________________________________________________________________
Why I tend not to use content negotiation
Author : TheBigRoomXXL
Score : 53 points
Date : 2023-11-19 21:07 UTC (1 hours ago)
(HTM) web link (htmx.org)
(TXT) w3m dump (htmx.org)
| xyzzy_plugh wrote:
| Content negotiation is surely a fire composed of tires but there
| are sadly many scenarios where it is necessary. Deciding whether
| to redirect for example is often context sensitive.
|
| In other words content negotiation is useful to be able to
| respond intelligibly. If a client asks you for json but not html,
| it might not make sense to return html.
| mschuster91 wrote:
| > Data APIs should be rate limited
|
| Hypermedia APIs should be rate limited as well, because otherwise
| people will just go and screen scrape (like many HN apps do,
| because HN doesn't offer an API). All a "data" API does is make
| the scraper's job easier.
|
| > Data APIs typically use some sort of token-based authentication
| / Hypermedia APIs typically use some sort of session-cookie based
| authentication
|
| So what. Any web framework worth its salt can support multiple
| authentication / credential mechanisms - the only "benefit" I can
| see from limiting cookie authentication is to make life for bad
| actors with cookie-stealer malware harder (like GitLab does,
| IIRC).
| benmanns wrote:
| Not anymore! https://github.com/HackerNews/API
| ronsor wrote:
| > Hypermedia APIs should be rate limited as well, because
| otherwise people will just go and screen scrape
|
| Then proxies or other IPs will be used anyway.
| serial_dev wrote:
| Hacker News has an API for a while now (I used it years ago
| around 2018), based on this post since 2014.
|
| Announcement https://www.ycombinator.com/blog/hacker-news-api
|
| API https://github.com/HackerNews/API
| afandian wrote:
| Tangential, but the lack of a "these types are available" as the
| counterpart to "Accept" has always been so obviously missing.
| What's the point of Accept if you don't know what to ask for?
|
| Maybe in the trivial case saying "I'd prefer a JPG to a PNG" can
| be an assymetrical choice. But in all the interesting use cases I
| can think of, e.g. where there are competing representation
| formats, you'd want the server to be able to respond to a HEAD
| with the choices.
|
| That's the kind of thing you can put in Swagger, but that might
| lead to hoisting the client's choice into the API, away from
| Content Negotiation.
| duskwuff wrote:
| The OPTIONS response already describes which methods are
| available for an endpoint in the Allow header. Including a list
| of available types in a new header would be a pretty natural
| extension. (Content-Type isn't available because it's defined
| to only contain a single media type.)
| mberning wrote:
| A technology like htmx seems to demand a "hypermedia" API.
| Whereas things like angular and react can consume a data API in
| many cases. However once an application becomes sufficiently
| complex people end up building data APIs just to suit their
| frontend framework. And in that case doing htmx and returning
| html seems nicer.
| simonbarker87 wrote:
| I've been building an app with HTMX over the past 6 months and
| this is the reason I am loving it. I don't even feel the
| backend/frontend interface, so rather than feeling like I am
| making the app twice (once in backend and again in the frontend
| to consume it) I am just making it once, there is no frontend,
| it's just all my app.
| candiddevmike wrote:
| Seems like a ton of added complexity to avoid using
| JavaScript/a fat client
| infecto wrote:
| Depends what you are trying to build. If you are building a
| complicated app that requires lots of states and you want it
| in the form of a SPA. Sure might be a bad fit.
|
| Lots of use cases could benefit from a hypermedia flow.
| Arch-TK wrote:
| Doing htmx is just as simple as doing server side rendering.
| Yes you still have a javascript dependency but that's a lot
| simpler than a client side javascript framework for pulling
| data out of a data API and rendering it client side.
|
| I don't think anyone's complaint about server side rendering
| has ever been that it was too complex.
| folsom wrote:
| I think the idea is that your hypermedia api and data api are
| not the same thing and the general shape of your data api
| should not be based on the needs of your front end.
| esjeon wrote:
| So, this is actually about: Why I Tend Not To Use Content
| Negotiation (to serve both HTML and JSON data from the same
| endpoints).
|
| The author also suggests:
|
| > The alternative is to ... splitting your APIs. This means
| providing different paths (or sub-domains, or whatever) for your
| JSON API and your hypermedia (HTML) API.
|
| I believe the alternative has been the norm actually. For
| example, many front-end frameworks encode UI states in URL, and
| it's not so sustainable to keep the alignment b/w UI states and
| data APIs in the long term.
| whalesalad wrote:
| I think content negotiation is great when your usecase supports
| it, like asking for XML or JSON. Also the mappings of content
| types should be well defined for all to see and edit. Rails is
| kinda a labyrinth in that regard.
|
| I do tend to prefer actual file extensions though. Friendlier for
| humans (curl https://endpoint/item.json vs curl -H "accept:
| application/json" https://endpoint/item), and it is visible in
| logging infrastructure, sharable, etc.
| qwertox wrote:
| For me it's always been a part of the query parameter
|
| http://endpoint/item?format=json or ?type=json
|
| I never ever had a problem with that. The only reason to use a
| file extension would be if the request would take no query
| parameters.
|
| It would never occur to me to use header information for this.
| simonw wrote:
| Cloudflare doesn't obey the Accept header on anything other than
| image content types.
|
| This means if you have an endpoint that returns HTML or JSON
| depending on the requested content type and you try to serve it
| from behind Cloudflare you risk serving cached JSON to HTML user
| agents or vice-versa.
|
| I dropped the idea of supporting content negotiation from my
| Datasette project because of this.
|
| (And because I personally don't like that kind of endpoint - I
| want to be able to know if a specific URL is going to return JSON
| or HTML).
| ForkMeOnTinder wrote:
| That's even with the proper Vary header, right? Seems like a
| cloudflare bug if that's true. Maybe even a security bug if you
| find a service that supports text/plain.
| shawn-butler wrote:
| Serious problem if true
| judge2020 wrote:
| I think you mean for CDN-cached content, right?
|
| The accept header is passed along, so your server can respond
| however it wants for dynamic content/not cached by CDN.
___________________________________________________________________
(page generated 2023-11-19 23:00 UTC)