This is a good post on The Ajax Response, discussing if it should be XML, HTML, or JSON. I personally think under no circumstances should it be HTML, or anything that includes markup. That violates the principle of separating the content from the style and it prevents reuse, by yourself and others.

I think deciding between JSON and XML is going to depend on your situation. XML is much more universal. With XML, you can create Web Services from your back end, and call them for display in PHP, JSP, and with Ajax. That Ajax call you are making today maybe a non-Ajax call you make later.

Google Suggest is a prime example of silliness. That data response is completely unusable in any other scenario. Perhaps, knowing Google, they have done this on purpose to prevent others from using that feed as freely, but it could be a handy service to offer and implement in other locations. The way Google has chosen to implement it, would require Google to have many versions of that response, for multiple uses.

With the rare exception, when you serve up data from your back end, think in big picture terms of making that data available to all your front end applications, and then apply style (HTML, CSS, etc) to it, once the data is in the front end.

UPDATE: Ignore my reservations about HTML in AJAX responses and see my followup post: AJAX Returning HTML (change of opinion).

In a previous post, I suggested I’d like to see a much looser coupling between the front-end, or GUI portion, of a web app, and the back-end, which handles data persistence, business rules, and all other types of data processing. Really, what I’m suggesting, is that these areas be broken down into separate unique services. The further we break components down, the easier it is to design them, code them, test them, and maintain them (at least to a point, you can go too far with this).

If you aren’t yet familiar with Service-Oriented Architecture, then read this post from several years ago on webservices.xml. It’s a good introduction to the concepts. So far in my experience, I think the GUI is being asked to do far too much; to be far too smart for its own good. I’d rather all the brains of the user interface be provided by services, and the front end simply stick to the role of providing a visual interface to those back-end services.

I still believe that Java is ideal for the back end portion of a web site or Internet application. When I say “back end”, I am referring to the data manipulation including the use of business rules and data persistence.

Its the use of Java on the front end, the web gui, that I’m not so sure I’m convinced of at this point. When JSP first came out, it seemed so simple, but then we began to get so concerned over separating roles and markup, content, and logic. Now creating a web site is just too much work. Lately, I’ve been using Word Press to do my blogs, and using Open Reports to create a reporting web site. Both of these are great examples of the simplicity in creating web sites. Open Reports creates forms to fill out with a simple web gui interface. Both of them require no “coding” in order to add further pages, change the look and feel, etc. They aren’t as custom as would be needed for most of the web applications I’ve worked on, but, I think we should be able to get to a point where the web front end is as simple as using Word Press, Open Reports, or any of the other CMS type web tools.

Read More »