CODEWITHSUNDEEP
asp.net-mvc-4asp.net-web-api
polonskyg
polonskyg

Reputation: 4319

WebApi and MVC 4: GetById and services in separate project

I'm working with webapi, MVC 4 project. (using repository pattern and Unit of Work) I have two questions

1) The GetById of WebApi should return the entity or HttpResponseMessage? If it's HttpResponseMessage, then Should it be...

[System.Web.Http.HttpGet]
public HttpResponseMessage Get(int id)
{
    var car = Uow.Cars.GetById(id);
    return car == null ? Request.CreateResponse(HttpStatusCode.OK, car) : Request.CreateResponse(HttpStatusCode.NotFound,);
}

or

[System.Web.Http.HttpGet]
public HttpResponseMessage Get(int id)
{
    var car= Uow.Cars.GetById(id);
    if (car!= null) {
        return car;
    }
    throw new HttpResponseException(new HttpResponseMessage(HttpStatusCode.NotFound));
}

I'd like to follow RESTfull responses.

2) Is it logical to separate webapi services from the UI? I mean in one webapi project, the controllers with base ApiController and CRUD http opearations, so they can be called from anywhere/any devices directly, and then another webapi/MVC4 project which will call the services of the webapi project?

I'm asking this because having in the same controller the service and the handling that return a View for example sounds like coupling the service to the client which will be consuming it.

For example: From this (in the same webapi controller):

[System.Web.Http.HttpGet]
public HttpResponseMessage Get(int id)
{
    var car = Uow.Cars.GetById(id);
    return car!= null ? Request.CreateResponse(HttpStatusCode.OK, car) : Request.CreateResponse(HttpStatusCode.NotFound,);
}

public ViewResult Details(long id)
{
    return View(Get(id));
}

Go to this:

public ViewResult Details(long id)
{
    return View(webapiService.Cars.Get(id));
}

Having the implementation of the Get in the service.

Upvotes: 1

Views: 1609

Answers (2)

VJAI
VJAI

Reputation: 32758

You could use HttpResponseMessage or the entity Car as the return type. If you use HttpResponseMessage you would get more control on customizing some of the HTTP properties when you create the response.

When the action creates a resource then using the HttpResponseMessage as the return type provide you much flexible option to set the status code (201) and the location where the created resource can be accessed. See this post for more info.

REST not care about which way you use all it cares is when the caller asks for a resource the server should return the resource in a format that the caller can accept it with proper status code (200 if exists else 404).

You can move the WebAPI controllers into separate project if there is really a choice that the service could be consumed from different clients else avoid doing that. Once you move the WebAPI controllers into a separate project then you will face Cross-Domain issues when you try to consume it from the javascript in MVC project.

Upvotes: 1

Sando
Sando

Reputation: 667

Point 1: It is logical to return the entity from actions in case of Web API but then we cannot control the HttpResponseMessage properties (like HttpStatusCode). Except that returning an entity is always a cleaner approach. We can control serialization, formatting etc in respective filters to get our job done. But you can never return car/HttpResponseMessage optionally as compiler will not let you compile a method with return type as HttpResponseMessage and return type Car.

Point 2: Having separate controllers for view and rest calls is a good idea. I would suggest to have controllers with the same name but in different namespaces and then routes handle http calls separately (but prepending '/api/' to the rest calls. Having different actions in the same controller for ViewResult and HttpResponseMessage/Car is an option also but not as clean and separate.

Upvotes: 0

Related Questions