Web Service VS. Aspx Pages: Pros and Cons

We develop an ASP.Net web application that is hosted on an internal network. Currently, we have some ASPX pages that handle web requests from the client side and interact with our servers. We are starting development on our next major application version, and we are deciding on the architecture.

What are the differences between using ASPX pages to handle http requests as compared to using a full blown Web Service (which would most likely be a WCF Service)?

In researching this issue, I have come across a few related posts that have been moderately helpful, seen here and here. My understanding of some of the key differences are as follows:

1. ASPX pages are limited in the kinds of requests they can receive. They are strictly HTTP whereas a WCF service can have multiple endpoints to service a variety of protocols (HTTP, TCP, etc).
2. WCF Services are more concretely defined due to ServiceContracts. This means that if a project makes a reference to the service, they know exactly what to expect in terms of methods, usage and documentation. An ASPX page is more of a free for all in terms of methods contained and requests accepted.

However, based on these concepts, my issues are as follows:

1. The ability to support different protocols is a great feature in terms of future proofing and compatibility, but what real benefit are we seeing if we are currently only using it to interact via HTTP?
2. In line with my previous argument, if we are only interacting with the service over a web, do any of those points really make any difference? An http request doesn't care about any of those finer details or contractual guarantees so long as the method it calls "just works".

Is there anything I am missing? Any key benefit to using a service? Personally, I support the Web Service architecture. I like the idea of having a flexible and well defined system that can support future development. What I am basically looking t开发者_开发百科o get out of this is a way to go to a coworker and say "This should be a service for x y z reasons and we could see a b c improvements for doing so".

WCF (and the older asmx-based web services) do a lot of the serialisation tasks for you. You can return objects from methods, and the framework will serialise those objects into the correct format XML and provide clients with the wsdl so they can call your webservice methods and understand what they're getting back.

You could do this with a web page (I bet there are loads of PHP "web services" out there), but you'd have to do all that plumbing yourself.

The type of request thing is WCF-magic. WCF has the notion of "endpoints" that allow you to separate the method of calling the service from what the service does. It's just a better (though many thing very complex) architecture that better separates those two concerns.

I doubt the performance bottleneck of any webservice would be the choice to use asmx rather than WCF. The performance penalties in web service architecture are almost always due to chatty interfaces and/or very large objects/object graphs. The very fact you're making a remote call to a webservice makes the difference in speed of WCF vs. asmx insignificant in most cases. WCF is more flexible in design, which is a valid reason to chose it. WCF does use the newer DataContractSerializer rather than the older method employed in axms, and supposedly it's a bit faster. I think you'd have to scale to quite a lot of users to see a meaningful difference though - you'd be better off looking for chatty interfaces and poorly performing db queries first.

Of course, if in doubt - measure first, then target specific areas of poor performance.

You shouldn't use an ASPX page as an improvised service endpoint, as often seen in the PHP world. Requests for ASPX pages are filtered through quite a few HttpModules that are unnecessary overhead for simple service endpoints, and each request creates an instance of the Page class for no reason.

ASMX is still a great option if all you need is a very simple endpoint that responds in XML or JSON.

WCF is very powerful if you need more flexibility and are willing to deal with the configuration burden.

Another option that is often overlooked is to use an HttpHandler. It's relatively simple/easy to throw together an ASHX HttpHandler, which gives you very "close to the metal" access to the request/response with much less overhead than an ASPX page.

I could be misunderstanding the question, but I'm not sure your comparison here is totally valid. You are comparing a page-and-service-delivery technology with relatively high overhead (ASPX pages) with pure service-only technologies (WCF and ASMX), right? I think a comparison of ASMX web services vs. WCF web services may be more valid, in which case WCF wins handily on configurability, not to mention performance: http://msdn.microsoft.com/en-us/library/bb310550.aspx

Also see WCF vs ASPX webmethods vs ASMX webmethods for a related question

Webservices can serialize your classes through proxies, you can't do that with a aspx page (AFAIK).

One way of doing this with ASP.NET pages is the pagemethods approach: http://aspalliance.com/1922_PageMethods_In_ASPNET_AJAX.all, which is very similar to the ASMX web services route. Everything that's been said I agree with, but the question is do you need a dedicated service to serve up data to the outside world, or are these services just to serve streaming data to the client internal to the application?

I took the page method approach in my link because most of the services were to facilitate AJAX within the page, and it kept the code all together. Additionally, the data can be retrieved via JQuery even with page methods, and it does support serialization and proxy generation.