Should my ajax calls talk to webservices or to simple webpages? It seems to be so much easier to simply Response.Write() the content. Are webservices more reliable or secure?
views:
589answers:
7Since the pages have a more complicated lifecycle, there is more overhead in calling a web page.
That said, I doubt it really matters in the end, but semantically and practically, a web page is not as efficient.
UPDATE: Can you clarify? Are you talking about typical ASP.NET pages? Or "Classic" ASP? As someone in comments on this answer pointed out, if we are talking "Classic" ASP, then it would be more simple than an ASP.NET page, but I think that goes without saying...
Not in any way I can see. It's all just http traffic going back and forth.
Web services are standardized so you get certain advantages out of using them, at least in regards to the Microsoft Development platform. You can point Visual Studio to a ASMX to add a reference from an external web service to your project - and while I'm sure you could get the same result from an *.aspx page you also have a lot of overhead associated with an *.aspx page (page lifecycle, viewstate).
If someone comes behind you to maintain your code, they may look at an *.aspx "web service" and scratch their head.
Depends on what libraries you are using to do the AJAX calls. It's nice to get JSON, or even better, the deserialized object, straight from your call, whatever the mechanism. Parsing SOAP is a chore you shouldn't have to worry about. That said, it's important to match up what's flowing in and out and that would affect my choice first. (Based on the constraints various managers/architects/etc might be handing down.)
I think that the answer ultimately depends on what you're doing with the site. If you have functionality that will/can be used across multiple pages or components, you're probably better off writing a web service to do the work.
Also, depending on the AJAX library/code that you are using, a web service may work better. Remember, a web service need not be a seperate site, but can be a .asmx page placed in an accessible location within your current site structure.
I have used a single .asmx file to return a control such things as login controls, UI dependent on users and integration of concurrent data updates from aWeb site and Windows Application.
All this being said, you can use the page behind, but often it is more practical for code reuse and cross site data handling to use a web service.
I don't think that SOAP web services offer an advantage over standard web pages. I would say however that REST-like web services are more appropriate. You can implement the REST-like web services in any way you want, including as an ASP page with simples Response.Write. Preferably you should return JSON objects. The important thing is to design your service properly, meaning to define which URL returns what content.
jQuery has a convenient getJSON function to read the server's response.
Something you might want to look into to make AJAX calls is Page Methods. With ASP.NET Page methods you can call a server side function that exists in your code behind using javascript, without the overhead of the page lifecycle, because the method has to be static. For more information about Page methods, check out
http://www.singingeels.com/Articles/Using_Page_Methods_in_ASPNET_AJAX.aspx
If you do want to access the functionality from your method on multiple pages, consider using a web service -- you can connect to it using the Microsoft AJAX javascript library in a similar way.