Pure Web Service(ASMX):

Starting back in 2002 with the original release of .NET, a developer could fairly easily create an ASP.NET

ASMX-based XML web service that allowed other .NET and non-.NET clients to call it.

Those web services implemented various versions of SOAP, but were only available for

use over HTTP.

 

.NET Remoting:

.NET Remoting essentially provides object activation and session context for client-initiated method calls. The caller uses a proxy

object to invoke methods, and the .NET runtime handles serialization and marshaling of data between the client’s proxy

object and the server’s activated service object.

 

Windows Communication Foundation (WCF):

Towards the end of 2006, Microsoft released .NET 3.0, which included the Windows

Communication Foundation (WCF). WCF not only replaced ASMX web services and

.NET Remoting, but also took a giant step forward in the way of flexibility, configurability,

extensibility, and support for more recent security and other SOAP standards.

For example, with WCF, a developer can write a non-HTTP service that supports

authentication with SAML tokens, and host it in a custom-built Windows service. These

and other capabilities greatly broaden the scenarios under which .NET can be utilized to

build a service-oriented application.

 

Now:

In addition to simpler protocol and security needs, web pages typically communicate

with other applications and services using text-based messages rather than binary-formatted

messages. As such, a service needs only to support XML or JSON serialization.

 

Advantages of Using the MVC Framework:

Speaking of REST, building services with ASP.NET MVC and the Web API provides most of

what you need to adhere to the constraints of the REST architecture. This is largely due to

the URL routing feature provided by the MVC Framework. Unlike WCF, where a service is

an address to a physical file (i.e., an address that maps directly to a service class or

.svc file), service addresses with MVC are REST–style routes that map to controller

methods. As such, the paths lend themselves very nicely to REST–style API specifications.

 

WCF Implementation

[ServiceContract]public interface ITaskService{[OperationContract]Task GetTask(long taskId);}public class TaskService : ITaskService{private readonly IRepository _repository;public TaskService(IRepository repository){_repository = repository;}public Task GetTask(long taskId){return _repository.Get
     
      (taskId);}}
     

MVC:

public class TasksController : Controller{private readonly IRepository _repository;public TasksController(IRepository repository){_repository = repository;}public ActionResult Get(long taskId){return Json(_repository.Get
     
      (taskId));}}
     

 

Web API:

public class TasksController : ApiController{private readonly IRepository _repository;public TasksController(IRepository repository){_repository = repository;}public Task Get(long taskId){return repository.Get
     
      (taskId);}}
     

One of the biggest changes is the base class used by the new controller,

ApiController. This base class was built specifically for enabling RESTful services, and

you simply return the object (or, objects in a collection) of the data being requested.

Contrast this with the ActionResult shown in the preceding MVC4 example. Further, the

URL itself will be different.

 

A QUICK OVERVIEW OF REST

Created by Roy Fielding, one of the primary authors of the HTTP specification,

REST is meant to take better advantage of standards and technologies within HTTP

than SOAP does today. For example, rather than creating arbitrary SOAP methods,

developers of REST APIs are encouraged to use only HTTP verbs.

* GET

* POST

* PUT

* DELETE

 

Web API Brief:

* Convention-based CRUD Actions:

HTTP actions (e.g., GET and POST) are automatically mapped to controller methods

(also known as controller actions) by their names. For example,

on a controller called Products, a GET request such as

/api/products will automatically invoke a method named “Get”

on the controller. Further, the Web API automatically matches

the number of arguments given in the URL to an appropriate

controller method. Therefore, the URL /api/products/32 would

automatically invoke the Get(long id) method. The same magic

also applies to POST, PUT, and DELETE calls.

* Built-in Content Negotiation:

In MVC, controller methods that return JSON or XML have to be hard-coded to specifically return

one of those content types. But with the Web API, the controller

method need only return the raw data value, and this value will be

automatically converted to JSON or XML, per the caller’s request.

The caller simply uses an Accept or Content-Type HTTP header

to specify the desired content type of the returned data, and the

Web API ensures your return value gets formatted appropriately.

Rather than returning an object of type JsonResult, you simply

return your data object (e.g., Product or IEnumerable<Product>).

* Automatic support for OData:

By simply placing the new [Queryable] attribute on a controller method that returns

IQueryable, clients can use the method for OData query

composition.

* Self-hosting:

With the Web API, you no longer need to use IIS to

host HTTP services. Now your REST services can be hosted in a

custom Windows service, console application, or any other type

of host you need.