There's nothing stopping an HTTP API from returning both HTML and JSON from the same endpoint. Just have the client send "text/html" or "application/json" in the Accept header, depending on what it needs.
There's nothing stopping an HTTP API from returning both HTML and JSON from the same endpoint. Just have the client send "text/html" or "application/json" in the Accept header, depending on what it needs.
One challenge is that JSON is for data and HTML is for UI. When a client gets JSON it can transform the data to make it ready for the UI. With HTML, the client is locked into the UI chosen by the server.
What if the client wants to render the output of an API in different ways depending on what screen is visible? If the server API outputs JSON, this is trivial. If it outputs HTML the client is stuck into rendering what the server gives it.
That's why GP mentioned the Accept header, the client can choose at runtime which one it wants.
However it would make sense to have a separate json api for other applications. That way the html endpoints can change without without api versioning, perfectly matching whatever the gui needs.
There absolutely is, this is just extra cruft you need to maintain, and who says that the HTML is universal enough to be used everywhere? This is exactly where a front-end or a backend-for-frontend (BFF) makes sense.