Hacker News Reader

Comment by bityard | Hacker News Reader

First let me say I love htmx. It's nice to be able to write a little web app with minimal javascript and fuss.

It's all well and good to have your API return HTML when your only client is a web browser. And for many applications (like many of mine) that is enough.

But HTTP APIs are most powerful when they are client-agnostic. JSON is terrible in so many ways but it is at least neutral ground: it can be consumed by any HTTP client (which need not be a web browser) and every programming language that matters. For my day job, I deal with a great many HTTP APIs that are never seen or used by a browser. Authentication systems, data storage, schedulers, etc

I can write a Python script that turns a JSON API response into a native Python object with a single line of code. How can you do _that_ with a HATEOAS response that is basically guaranteed to contain arbitrary HTML?

View on HN

> I can write a Python script that turns a JSON API response into a native Python object with a single line of code. How can you do _that_ with a HATEOAS response that is basically guaranteed to contain arbitrary HTML?

HATEOAS can be (and often is) done with JSON or JSON-based (e.g., JSON+JSONSchema) representation for “backbone” resources (the same resources might also be available in HTML; HATEOAS and HTTP both are designed to accommodate representation being flexible for the same resource.

But, sure, you can also do a one-line parse of raw HTML into a python object. Just as with raw JSON, you’ll probably lose some intended semantics, with either you’ll need to use a format based on the root format but with more tightly defined semantics to do a one-line client that doesn't lose meaning. For JSON, JSON+JSONSchema may be enough for many applications. For HTML, Microformats2 may be enough for many applications.

> Microformats2

Not only that, those metadata are basically enforced by the big closed garden internet players if you want to use any nice embedding; so you need those anyways.

RPC has its place in life, but hypermedia is extremely powerful for application development. I believe many systems would be best served by providing both: a hypermedia-based web application and a JSON-based data API. This essay on the topic may be of interest to you:

https://htmx.org/essays/splitting-your-apis/

If the response is xhtml then de-serialization as easy as with json

I think XHTML is largely a distraction here since the 2000s. HTML5 standardized parsing and the mechanisms for including non-display data.

Since the decline of IE8 or so, almost all of the work I’ve had working with data in HTML has been due to differences in the data models, which is also a problem using JSON or XML.

These aren't equivalent scenarios. The JSON response is a programmatic endpoint so of course it only contains programmatically-relevant data. Typically the HTML is not from a programmatic endpoint, but it could be.

Strip out all styling and non-programmatic content from an endpoint that returns HTML and you basically have pseudo-XML document that can just easily be mapped to a native object as JSON, with the added benefit that you can actually identify links without needing a separate schema as you do with JSON. This isn't typically done but there's no reason it can't be done.

In fact, it would be considerably more powerful than JSON because you can actually transmit functions. For instance, a <form> input and its associated inputs can be translated into a native function with parameters whose names correspond to the input names that makes a remote call. So theoretically, hypertext is JSON + first-class functions. This is why HATEOAS is more flexible.

With htmx the size and complexity of web client should be radically reduced compared to a heavy JS client app consuming the JSON API. I reckon this could free one up to make an API that was specialised for native clients and possibly even the web server itself… maybe no JSON in sight, unless you were keen.

Frankly, I think that HTML can likely be consumed in more languages than JSON by sheer virtue of age.

And there are any number of ways you could standardize the format of your HTML response - such that people who know the formatting ahead of time get the exact same benefits as they would with JSON.

What if we simply move the JSON -> HTML translation layer from the client, to a layer just before egress from the server? Maybe we provide two output options for each endpoint: /foo/1/bar (HTML by default) and /foo/1/bar?format=json

...that's a mechanism already built into HTTP in the form of Accept header. There's something called "content negotiation"[1], which seems to be there since the 90s. Not sure about other frameworks, but the Django REST[2] Framework at least implements this correctly and can serialize to XML or JSON transparently.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_ne...

[2] Of course, the framework has nothing to do with REST at all. I gave up telling people this many years ago - it just doesn't work... Mentioning it here since it's relevant to the topic.

Note however that content negotiation has historically been complicated by things like caching or client oddities setting headers. Many of the projects where I’ve used it on have ended up adding a way to specify the format in the URL, although that has become less of a concern over time.

What about /bar.html and /bar.json ?

> How can you do _that_ with a HATEOAS response that is basically guaranteed to contain arbitrary HTML?

https://pypi.org/project/mechanize/

Reply on news.ycombinator.com