5 ms·

> How does one use this for AJAX without rewriting existing backends? I've never actually used a backend that couldn't return arbitrary content types. Those ex

> How does one use this for AJAX without rewriting existing backends? I've never actually used a backend that couldn't return arbitrary content types. Those exist?

capableweb 6y ago
This is exactly the use-case for Content-Type and Accept headers. The client and server negotiates what type of content they can receive/send, so if you're sending application/json as the Accept header, you can only handle application/json, if you only send text/html in the header, then only HTML. If the client understands both, you do application/json,text/html. with the order signalling preference. Any serious framework would be able to handle this without any hiccups.
- nogabebop23 6y ago
  THat's how you negotiate the content type; the original question was how they have a service returning json return html. I've never heard of a framework that can arbitrarily convert data into HTML - how would that even work?
  - pseudosavant 6y ago
    You could dynamically create HTML that mirrored a JSON response. You'd just have to have to walk the JSON structure and create a structure for where the key and the value from the JSON end up. Each node could just be a <div>. The ID could be a composition of the key and the parent nodes/keys so that it'd be unique. You could also stuff both values in a data-* attribute. It wouldn't be the prettiest HTML but you could work with it via CSS and JS.
  - capableweb 6y ago
    I was part of a project that when I just joined it, RESTful APIs together with fat frontend clients was becoming the hot-new-thing. The application was originally returning text/html (templates) to be injected in various part of the frontend, at request-time. To migrate to our flashy new Angular V1 application, we added a application/json content-type that instead of returning the template, returned the data that the template used. So we could endpoint-by-endpoint migrate to the SPA we were building. Was simply a matter of making the data required for the views a bit more advertised internally, so the controllers could instead not render the views when the content-type is json.
wenc 6y ago
> Those exist? For sure. Most of the backends we write only return JSON. If you request HTML or any other content-type, we return nothing. We just don't implement it. If you write your backend from scratch and only intend for it to be used only with your web front-end, you can make it return bits of HTML (I have several applications in jQuery that work like this -- the value of the response just gets inserted via ("#id").html(val)). Our current backends are written to support multiple generic consumers of which a web front-end is only one.
- RyanGoosling 6y ago
  But it could
  - wenc 6y ago
    Sure but it’s extra engineering time (tiny per instance yes but multiplied over many legacy apps with no value add — not an easy business case to make just to use a html based front end library.) Much easier to use client-side templating as suggested by the author.

> How does one use this for AJAX without rewriting existing backends? I've never actually used a backend that couldn't return arbitrary content types. Those exist?

capableweb 6y ago

This is exactly the use-case for Content-Type and Accept headers. The client and server negotiates what type of content they can receive/send, so if you're sending application/json as the Accept header, you can only handle application/json, if you only send text/html in the header, then only HTML. If the client understands both, you do application/json,text/html. with the order signalling preference. Any serious framework would be able to handle this without any hiccups.

nogabebop23 6y ago
THat's how you negotiate the content type; the original question was how they have a service returning json return html. I've never heard of a framework that can arbitrarily convert data into HTML - how would that even work?
- pseudosavant 6y ago
  You could dynamically create HTML that mirrored a JSON response. You'd just have to have to walk the JSON structure and create a structure for where the key and the value from the JSON end up. Each node could just be a <div>. The ID could be a composition of the key and the parent nodes/keys so that it'd be unique. You could also stuff both values in a data-* attribute. It wouldn't be the prettiest HTML but you could work with it via CSS and JS.
- capableweb 6y ago
  I was part of a project that when I just joined it, RESTful APIs together with fat frontend clients was becoming the hot-new-thing. The application was originally returning text/html (templates) to be injected in various part of the frontend, at request-time. To migrate to our flashy new Angular V1 application, we added a application/json content-type that instead of returning the template, returned the data that the template used. So we could endpoint-by-endpoint migrate to the SPA we were building. Was simply a matter of making the data required for the views a bit more advertised internally, so the controllers could instead not render the views when the content-type is json.

wenc 6y ago

> Those exist? For sure. Most of the backends we write only return JSON. If you request HTML or any other content-type, we return nothing. We just don't implement it. If you write your backend from scratch and only intend for it to be used only with your web front-end, you can make it return bits of HTML (I have several applications in jQuery that work like this -- the value of the response just gets inserted via ("#id").html(val)). Our current backends are written to support multiple generic consumers of which a web front-end is only one.

RyanGoosling 6y ago
But it could
- wenc 6y ago
  Sure but it’s extra engineering time (tiny per instance yes but multiplied over many legacy apps with no value add — not an easy business case to make just to use a html based front end library.) Much easier to use client-side templating as suggested by the author.