How can I return generated HTML and a response too?

Question

My web application will use AJAX calls often and so I have set up some JavaScript to handle "messages" or "responses". These responses are returned (from my ASP.NET application) as JSON objects that act as feedback once a function is complete.

Suppose my responses have three basic elements.

• Type (error, warning, info, success)
• Title
• Message

For example

Save unsuccessful

Your data was not saved because of XYZ.

Sometimes, however, I want my function to generate and return some HTML. That's easy enough, but what if I still want to return a message to the user (or some other JSON)?

• Should I return the HTML as part of the JSON?
• Should I only return one or the other?
• Should I return HTML, then make another AJAX call for the response?
• Should I return HTML and store the response in data- tags?

Can someone point me in the right direction?

Answer 1

Should I return HTML, then make another AJAX call for the response?

Unless you have some compelling reason not to (there aren't any I can think of), you should definitely favor minimizing the number of calls. Each call has the overhead of URL resolution/etc. and if you're just getting the same data you'd send anyway in the single call, there's no reason for that waste.

Should I return the HTML as part of the JSON?

Returning HTML in JSON is fine, if you're using jQuery (or even naked DOM access), it's easy to update the HTML of an element. If you don't need the HTML message, that property can be null or omitted entirely, so it wouldn't be wasteful to include it only in the cases where you need it.

Should I only return one or the other?

From the ASP.NET function? I think it's probably best to include the HTML property as part of a standard protocol. For example, I have 3 standard properties from all AJAX calls: Success, ErrorMessage, ErrorTitle. This keeps it easier for someone to work with as well since they can rely on those being there all the time and act accordingly.

Should I return HTML and store the response in data- tags?

You might have a use case where this makes sense, but I think in general, it makes more sense to have JS functions for responding to the standard message protocol instead. This way it allows the caller more control over how, when, where, etc. the messages display. You can also come up with sensible defaults that can be overridden if there's a need.

Answer 2

A best practice is to keep the reply consistent, meaning you should always have JSON offering a structure which is consistent and provides enough information to infer whether or not the call was a success.

First check the ajax status that the command was properly handled. Once you've determined that the command was properly handled, you then proceed to check your json, in particular some sort of indicator which implies whether or not your internal program could handle that particular request.

If both are correct, then you search for an additional property which you must guarantee to always be there which contains the HTML string. If something goes wrong, then you search for an additional property which you must guarantee in case of failure which contains the error message.

What is important is that you always have an indicator of success to let you know what to expect from the response. This is of course completely arbitrary, but best practice dictates that if the ajax command went well, that you should provide enough information such that your javascript program knows what to do next.

Answer 3

Disclaimer: This answer disagrees with the current accepted answer. Keep an open mind and see why. We're all just trying to share knowledge here anyway right? Skip to end for TL;DR

For anyone stumbling upon this now, this answer tries to stick to the design pattern of MVC in context of the web defined simply below:

• Model: the data persistence layer
• View: the templating system
• Controller: action that gets data and gives it to a certain view

I won't explain the reason for the separation just known that this design pattern is known to be more scalable when it is followed appropriately.

A few more terms (the acronyms really mean nothing):

• AJAX: nothing more than a technique that uses javascript to get data and update that page instead of refreshing the page
• JSON: a structured data standard

---

Should I return the HTML as part of the JSON?

No, JSON should only be representations of data. This is part of the 'model' in MVC. If you're returning rendered HTML in your JSON then you can't change the view implementation. Once you get the rendered HTML, you're stuck with it.

Should I only return one or the other?

Yup, JSON is part of the 'model' because it represents data. HTML is part of the 'view'. When you have HTML in a JSON response, you're returning data with a view in it. I believe this doesn't follow MVC.

If anyone is specifically using ASP.NET, I would recommend returning a PartialView when you want to 'return just HTML' when AJAXing. Keep in mind that you only should return a partial view when wanting to change a certain part of the page without refreshing all of it (def of AJAX). This answer might help.

Should I return HTML, then make another AJAX call for the response?

This question may be worded weird. I'm assuming that the goal in context is to update the page without refreshing all of it--aka AJAX. When "returning HTML" you make an AJAX call for HTML and you update a certain part of the page from the rendered HTML. It doesn't make sense to make two AJAX calls because the AJAX call you make for HTML should already have a rendered 'view' with information inside it.

If you make an AJAX call for just data (in JSON form), then you would take that data and manipulate the DOM using the data i.e. Create an element and put data.message in there.

Should I return HTML and store the response in data- tags?

No, I don't think that would make sense. What you're trying to do is save the 'state' of the document in data- tags and you should just be 'saving state' by simply changing the text of the elements themselves.

---

TL;DR The end goal of AJAX calls is to change the state of the DOM without refreshing the page. You should make AJAX for data (in the form of JSON) not rendered HTML because this is far more flexible and reusable.

Make an AJAX call for data then use javascript to change the page.

Answer 4

Keep your interface and implementation simple. Since you're using http request, you should take advantage of its features. For example, instead of creating new interface "type", you can use http status code.

If you use http status code, then on your javascript side, you can take that advantage too. For example, if you use jquery, it has handlers for your ajax calls which uses http status code as a factor to decide if it should call error or success handler.

If you still need to return json & html, you have your interface returning data in both format based on http Accept header value set by the client when making ajax call. Then your code for displaying html doesn't need to know about the returned data format because it only gets what it needs, which html.