https://ics.uci.edu/~fielding/pubs/dissertation/net_arch_sty...
The server MUST be stateless, the client MAY be stateful. You can't get ETags and stuff like that without a stateful client.
https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_st...
> any concept that might be the target of an author's hypertext reference must fit within the definition of a resource
It's an optional constraint. It's valid for CSS, JavaScript and any kind of media type that is negotiable.
> resource: the intended conceptual target of a hypertext reference
> representation: HTML document, JPEG image
A resource is abstract. You always negotiate it, and receive a representation with a specific type. It's like an interface.
Therefore, `/style.css` is a resource. You can negotiate with clients if that resource is acceptable (using the Accept header).
"Presentation layer" is not even a concept for REST. You're trying to map framework-related ideas to REST, bumping into an impedance mismatch, and not realizing that the issue is in that mismatch, not REST itself.
REST is not responsible for people trying to make anemic APIs. They do it out of some sense of purity, but the demands do not come from HATEOAS. They come from other choices the designer made.
I'm realizing/remembering now that our internal working group's concept of HATEOAS was, apparently, much stricter to the point of being arguably divergent from Fielding's. For us "HATEOAS" became a flag in the ground for defining RESTful(ish) API schemas from which a user interface could be unambiguously derived and presented, in full with 100% functionality, with no HTML/CSS/JS, or at least only completely generic components and none specific to the particular schema.
