SPAs are for humans, but they let you have structured data.
That's the problem here. People need APIs, which means not-for-humans, and so to find an efficient way to get "pages" for humans and APIs for not-humans they invented SPAs that transfer data in not-for-humans encodings and generate or render it from/to UIs for humans. And then the intransigent HATEOAS boosters come and tell you "that's not RESTful!!" "you're misusing the term!!", etc.
Look at your response to my thoughtful comment: it's just a dismissive one-liner that helps no one and which implicitly says "though shall have an end-point that deals in HTML and another that deals in JSON, and though shall have to duplicate effort". It comes across as flippant -- as literally flipping the finger[0].
No wonder the devs ignore all this HATEOAS and REST purity.
[0] There's no etymological link between "flippant" and "flipping the finger", but the meanings are similar enough.
Yeah, that was too short a response, sorry I was bouncing around a lot in the thread.
The essay I linked to somewhat agrees w/your general point, which is that hypermedia is (mostly) wasted on automated consumers of REST (in the original sense) APIs.
I don't think it's a bad thing to split your hypermedia API and your JSON API:
(Those costs will typically be dwarfed by data store access anyway)
So, all in all, I kind of agree with you on the pointlessness of REST purity when it comes to general purpose APIs, but disagree in that I think you can profitably split your application API (hypermedia) from your automation API (JSON) and get the best of both worlds, and not duplicate code too much if you have a proper model layer.
> So, all in all, I kind of agree with you on the pointlessness of REST purity when it comes to general purpose APIs, but disagree in that I think you can profitably split your application API (hypermedia) from your automation API (JSON) and get the best of both worlds, and not duplicate code too much if you have a proper model layer.
I've yet to see what I proposed, so I've no idea how it would work out. Given the current state of the world I think devs will continue to write JS-dependent SPAs that use JSON APIs. Grandstanding about the meaning of REST is not going to change that.
> I think you can profitably split your application API (hypermedia) from your automation API (JSON)
Why split them? Just support multiple representations: HTML and JSON (and perhaps other, saner representations than JSON …) and just let content negotiation sort it all out.
SPAs are for humans, but they let you have structured data.
That's the problem here. People need APIs, which means not-for-humans, and so to find an efficient way to get "pages" for humans and APIs for not-humans they invented SPAs that transfer data in not-for-humans encodings and generate or render it from/to UIs for humans. And then the intransigent HATEOAS boosters come and tell you "that's not RESTful!!" "you're misusing the term!!", etc.
Look at your response to my thoughtful comment: it's just a dismissive one-liner that helps no one and which implicitly says "though shall have an end-point that deals in HTML and another that deals in JSON, and though shall have to duplicate effort". It comes across as flippant -- as literally flipping the finger[0].
No wonder the devs ignore all this HATEOAS and REST purity.
[0] There's no etymological link between "flippant" and "flipping the finger", but the meanings are similar enough.
Yeah, that was too short a response, sorry I was bouncing around a lot in the thread.
The essay I linked to somewhat agrees w/your general point, which is that hypermedia is (mostly) wasted on automated consumers of REST (in the original sense) APIs.
I don't think it's a bad thing to split your hypermedia API and your JSON API:
https://htmx.org/essays/splitting-your-apis/
(NB, some people recommend even splitting your JSON-for-app & JSON-for-integration APIs: https://max.engineer/server-informed-ui)
I also don't think it's hard to avoid duplicating your effort, assuming you have a decent model layer:
https://htmx.org/essays/mvc/
As far as efficiency goes, HTML is typically within spitting distance of JSON particularly if you have compression enabled:
https://github.com/1cg/html-json-size-comparison
And is also may be more efficient to generate because it isn't using reflection:
https://github.com/1cg/html-json-speed-comparison
(Those costs will typically be dwarfed by data store access anyway)
So, all in all, I kind of agree with you on the pointlessness of REST purity when it comes to general purpose APIs, but disagree in that I think you can profitably split your application API (hypermedia) from your automation API (JSON) and get the best of both worlds, and not duplicate code too much if you have a proper model layer.
Hope that's more useful.
Thanks, I appreciate the detailed response.
> So, all in all, I kind of agree with you on the pointlessness of REST purity when it comes to general purpose APIs, but disagree in that I think you can profitably split your application API (hypermedia) from your automation API (JSON) and get the best of both worlds, and not duplicate code too much if you have a proper model layer.
I've yet to see what I proposed, so I've no idea how it would work out. Given the current state of the world I think devs will continue to write JS-dependent SPAs that use JSON APIs. Grandstanding about the meaning of REST is not going to change that.
9 replies →
> I think you can profitably split your application API (hypermedia) from your automation API (JSON)
Why split them? Just support multiple representations: HTML and JSON (and perhaps other, saner representations than JSON …) and just let content negotiation sort it all out.
1 reply →