On 22/02/2008, at 2:15 PM, Mat wrote:
> What are the benefits of using either implementation? Obviously the
> second way is not typical AJAX due to the lack of XML - but its the
> same
> idea. Also, are there any security related issues due to using either
> method?
Separation of concerns. From a design point of view, it's much cleaner
to have your calls to the web server return a dumb data structure
(These days JSON is just as common an AJAX response as XML), and make
the script doing the request responsible for manipulating that data
and putting it back in the page.
Doing it this way is easier to test because your server-side service
has a much simpler contract and returns a result that can be parsed
and verified independently of the display logic in the page. It makes
it easier to maintain the page, because all the logic about what goes
where and how is in the page logic, not divided between the page and
whatever server-side AJAX processors are sending scripts over the
wire. It also makes it possible to re-use the same AJAX call in
different contexts.
Also, from a security point of view, there are probably fewer things
that can go wrong if you're expecting (and working on) a specific data
structure than can go wrong if you're just blatting arbitrary text
into the browser's Javascript interpreter.
C
-------------------------------------------------------------------------
Sponsored by: Watchfire
Methodologies & Tools for Web Application Security Assessment
With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F
-------------------------------------------------------------------------
Received on Feb 22 2008
Intro
