ASP.NET MVC & Web API Brief Introduction

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

http://MyServer/TaskService.svc

[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<Task>(taskId);
}
}

MVC:

http://MyServer/Task/Get/123

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

Web API:

http://MyServer/Tasks/123

public class TasksController : ApiController
{
private readonly IRepository _repository;
public TasksController(IRepository repository)
{
_repository = repository;
}
public Task Get(long taskId)
{
return repository.Get<Task>(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.