How to (auto) generate a webapi controller for MVC + Entity or generically query all types

Question

Being new to MVC4 + Entity + WebAPI I was frustrated that in order to simply have GET, POST controller handlers and custom mappings to data models.

What I guess I'm asking is there a generation tool to, for instance make your controller class from your data class so I can just do simple GET commands right from the data?

What is the approach to make a generic RESTful API so commands could be made as such

GET api/1.0/{genericdatatype}/{id}

where the generic data type can be any model and no specific controllers? Say I don't need PUT (handled through the MVC app) so I don't really need POST validation etc.

I guess the initial reason I wanted this was because I had front-end devs waiting around to start integrating services. It would have been great if I could have 'pooped out' a basic CRUD API without any work. But, if you're willing to give up RDB (and only use for cold storage) and go document store, you're problem is alleviated. — FlavorScape, Mar 11 '14 at 18:09

score 3 · Accepted Answer · edited May 23 '17 at 10:28

3

There is a tool/package called MVC Scaffolding that will build out your controllers based on your models.

http://mvcscaffolding.codeplex.com/

http://blog.stevensanderson.com/2011/01/13/scaffold-your-aspnet-mvc-3-project-with-the-mvcscaffolding-package/

As for the generic piece, that's a very long and difficult process that would take a good deal of time. I'd love to see that as well if someone has a good answer for it.

EDIT: I have spent some additional time looking into the generic piece. It looks like someone else had a similar thought and asked a nearly identical question here: Generic Web Api controller to support any model.

At the end of the day, they voice some excellent concerns in that conversation. How do you handle different types of IDs? Would they always need to be strings and then parsed out? And once you get into more business rules I suspect that you'd have a very complicated business layer behind the controller. That said, I'd say you're better off sticking with straight scaffolding rather than building out a generic API. Sure, it could probably be done, but at what cost in time and crazy parsing code behind the API? Just my thoughts.

edited May 23 '17 at 10:28

Community

1
1

answered Jan 23 '13 at 22:42

David L

32,885
8
62
93

MVC4 + Entity is essentially scaffolding... What I'm looking for is a tool to enable generic rest commands (possibly generated) from the Entity Framework model. You've got all the models, I don't understand why you'd have to manually add a controller to render each datatype. – FlavorScape Jan 24 '13 at 00:15
If you are going to use scaffolding there is a web api specific on Install-Package WebApi.Scaffolding http://webapiscaffolding.codeplex.com/ – Mark Jones Jan 24 '13 at 09:01
@FlavorScape I added an additional stack overflow conversation link. At the end of the day, I think that type of generic API Controller would probably be more trouble than it's worth. – David L Jan 24 '13 at 15:19
i'm pretty done with SQL at this moment. Why not have generics. NoSQL is the way to go. generic everything, enforce strict relationships with proper hash indexes... – FlavorScape Feb 24 '13 at 01:07

score 3 · Answer 2 · answered Sep 22 '13 at 20:39

Probably this answer is too late for the original poster, but perhaps others can use this.

I just cooked up this generic base api controller for MVC 5 code first CRUD operations:

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.Entity;
using System.Data.Entity.Infrastructure;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Web.Http;
using My.Models;
using System.Data.Entity.Validation;

namespace My.Controllers.Api
{
  public abstract class CrudController<TEntity>
    : ApiController where TEntity : class
  {
    private readonly MyContext _db = new MyContext();
    private readonly DbSet<TEntity> _dbSet;

    protected CrudController(Func<MyContext, DbSet<TEntity>> dbSet)
    {
      _db = new EtlContext();
      _dbSet = dbSet(_db);
    }

    public IEnumerable<TEntity> Get()
    {
      return _dbSet.AsEnumerable();
    }

    public HttpResponseMessage Post(TEntity entity)
    {
      try
      {
        if (!ModelState.IsValid)
          return Request.CreateResponse(HttpStatusCode.BadRequest);

        _db.Entry(entity).State = EntityState.Added;

        _db.SaveChanges();

        return Request.CreateResponse(HttpStatusCode.Created);
      }
      catch (DbEntityValidationException)
      {
        return Request.CreateResponse(HttpStatusCode.BadRequest);
      }
      catch (DbUpdateException)
      {
        return Request.CreateResponse(HttpStatusCode.Conflict);
      }
    }

    public HttpResponseMessage Put(TEntity entity)
    {
      try
      {
        if (!ModelState.IsValid)
          return Request.CreateResponse(HttpStatusCode.BadRequest);

        _db.Entry(entity).State = EntityState.Modified;

        _db.SaveChanges();

        return Request.CreateResponse(HttpStatusCode.OK);
      }
      catch (DbEntityValidationException)
      {
        return Request.CreateResponse(HttpStatusCode.BadRequest);
      }
      catch (DbUpdateConcurrencyException)
      {
        return Request.CreateResponse(HttpStatusCode.NotFound);
      }
      catch (DbUpdateException)
      {
        return Request.CreateResponse(HttpStatusCode.Conflict);
      }
    }

    public HttpResponseMessage Delete(TEntity entity)
    {
      try
      {
        _db.Entry(entity).State = EntityState.Deleted;

        _db.SaveChanges();

        return Request.CreateResponse(HttpStatusCode.OK);
      }
      catch (DbUpdateConcurrencyException)
      {
        return Request.CreateResponse(HttpStatusCode.NotFound);
      }
    }

    protected override void Dispose(bool disposing)
    {
      _db.Dispose();
      base.Dispose(disposing);
    }
  }
}

I still had to make subclasses for each DbSet like this:

public class CustomersController 
  : CrudController<Customer>
{
  public CustomersController()
    : base(db => db.Customers)
  {}
}

public class ProductsController 
  : CrudController<Product>
{
  public ProductsController()
    : base(db => db.Products)
  {}
}

to make this routing work:

config.Routes.MapHttpRoute(
    name: "DefaultApi",
    routeTemplate: "api/{controller}",
 );

score 1 · Answer 3 · answered Feb 04 '16 at 21:54

I'm offering an alternative myself that our team has adopted. OData. Its a quick way to build your initial RESTful template, with more emphasis on querying than CRUD, it makes data available without having to build out endpoints yourself, manually. I'm doing the front end now for a project that has OData on the Web API server and this works brilliantly to free up the back end devs to work on more pressing matters than collections endpoints.

It works with Entity framework, too.

How to (auto) generate a webapi controller for MVC + Entity or generically query all types

3 Answers3

Linked