Is ASP.NET MVC a good option for developing a Services layer and/or API?

Is 开发者_Go百科ASP.NET MVC a good option for developing a Services layer and/or API? If so, are their any solid examples out there for reference. ASP.NET MVC views are generally tied to aspx pages, but how would I go about making my views in the form of XML or JSON?

In the scenario I am proposing, I'll have an ASP.NET MVC front-end which will consume n Services tier that will also be exposed as a public API.

---

You can create controller methods that return different ActionResult types besides views. Here are the possible ActionResult types already built into ASP.NET MVC:

System.Web.Mvc.ContentResult
System.Web.Mvc.EmptyResult
System.Web.Mvc.FileResult
    System.Web.Mvc.FileContentResult
    System.Web.Mvc.FilePathResult
    System.Web.Mvc.FileStreamResult
System.Web.Mvc.HttpUnauthorizedResult
System.Web.Mvc.JavaScriptResult
System.Web.Mvc.JsonResult  <----  Here is the one for JSON
System.Web.Mvc.RedirectResult
System.Web.Mvc.RedirectToRouteResult
System.Web.Mvc.ViewResultBase
    System.Web.Mvc.PartialViewResult
    System.Web.Mvc.ViewResult

In addition, you can write your own ActionResult that returns a type of your choosing.

---

If you're making a restful service I think MVC would be great. If you want to support WS* webservice standards then you should probably use WCF. Personally I think WCF is a lot of pain/overhead that isn't necessary if you're just doing a RESTful service. WCF tends to bypass parts of the IIS and ASP.NET stack which can cause surprise pains (or pleasure, if you enjoy working with/configuring WCF).

---

You'd be much better served by using WCF (Windows Communication Foundation) for this...at least in my opinion.

WCF can be used to build a multitude of services, but also allows you to specify different endpoints for the same WCF Service. This means that you can offer a much more flexible public API (RESTful Web Services, SOAP Based Web Services with WS-* Standards, etc.) while writing a lot less code.

---

To substantiate Justin's answer that WCF is the way to go, using WCF provides you with a platform that abstracts the transport details. This allows you to switch (or offer multiple) transports at configuration-time. If you find that a web-based JSON/REST solution does not provide adequate performance and you don't need cross-platform interoperability, you can change the service to TCP-based, or pipes-based, via configuration. The ASP.NET MVC approach, on the other hand, offers no such option, although you do gain a higher degree of control over the behavior of the service.