API web en solución MVC en proyecto separado

Estoy creando un nuevo proyecto MVC4 y la investigación me ha llevado a creer que la comunicación desde javascript al lado del servidor se logra mejor ahora a través del marco de la API web en lugar de las acciones del controlador. ¿Es correcto mi entendimiento sobre esto?

Supongo que puedo compartir todos mis atributos, etc.entre la API web y los controladores MVC, por lo que, a primera vista, no parece un cambio masivo para mí.

Cuando estoy configurando aplicaciones, me gusta dividir componentes en proyectos. Mi plan era tener un proyecto MVC y un proyecto de API web. Pero me he encontrado con problemas. Por ejemplo, terminé con 2 aplicaciones como tales, configuración de enrutamiento separada, etc., etc.

Entonces, mi pregunta es, en una aplicación MVC, ¿el marco de la API web debería ubicarse dentro del mismo proyecto, o la API web debería separarse en un proyecto propio y solucionar los problemas?

Desafortunadamente, se equivoca al respecto: supongo que puedo compartir todos mis atributos, etc.entre los controladores web api y mvc, por lo que, a primera vista, no parece un cambio masivo para mí.

Muchos de los conceptos utilizados por Web API y MVC, aunque similares a primera vista, en realidad no son compatibles. Por ejemplo, los atributos de la API web son System.Web.Http.Filters.Filtery los atributos de MVC son System.Web.Mvc.Filter, y no son intercambiables.

Lo mismo se aplica a muchos otros conceptos: enlace de modelos (mecanismos completamente diferentes), rutas (la API web usa HTTPRoutes no Routes, aunque ambos operan en la misma RouteTable subyacente), resolución de dependencias (no compatible) y más, aunque similar en el superficie, son muy diferentes en la práctica. Además, Web API no tiene un concepto de áreas.

En última instancia, si todo lo que está tratando de lograr es tener una forma "nueva y moderna" de ofrecer contenido JSON, piénselo dos veces antes de seguir ese camino. Ciertamente, no recomendaría refactorizar ningún código existente a menos que realmente esté buscando adoptar HTTP y construir su aplicación de una manera REST.

Realmente todo depende de lo que estés construyendo. Si está comenzando un nuevo proyecto, y todo lo que necesita es ofrecer algo de JSON para facilitar su aplicación web, siempre que esté dispuesto a vivir con algún código potencialmente duplicado (como el que mencioné anteriormente), la API web podría alojarse fácilmente en el mismo proyecto que ASP.NET MVC.

Solo separaría la API web en un proyecto separado si va a crear una API adecuada para su servicio en línea, tal vez para ser consumida por clientes externos o por varios dispositivos, como alimentar sus aplicaciones móviles.

En mi opinión, la seguridad y la implementación deben impulsar su decisión. Por ejemplo, si su aplicación MVC usa autenticación de formularios pero está interesado en usar la autenticación básica (con SSL) para su API, los proyectos separados le facilitarán la vida. Si desea alojar su sitio en www.example.com pero alojar su API como api.example.com (frente a www.example.com/api), los proyectos separados le facilitarán la vida. Si separa sus proyectos y los subdominios en consecuencia y tiene la intención de aprovechar su propia API desde su aplicación MVC, tendrá que averiguar cómo tratar el problema de la Política del mismo origen para las llamadas del lado del cliente a su API. Las soluciones comunes a esto son aprovechar jsonp o CORS (preferiblemente si puede).

Actualización (26/3/2013): Se acerca el soporte oficial de CORS: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API

Después de cierto grado de experiencia (creando API para aplicaciones y para mvc). Principalmente hago ambas cosas.

Creo un proyecto separado para las llamadas a la API que provienen de otros clientes u otros dispositivos (aplicaciones Android / IOS). Una de las razones es que la autenticación es diferente, se basa en tokens (para mantenerla sin estado). No quiero mezclar esto dentro de mi aplicación MVC.

Para mis llamadas de API javascript / jquery a mi aplicación MVC, me gusta simplificar las cosas, así que incluyo una API web dentro de mi aplicación MVC. No tengo la intención de tener una autenticación basada en tokens con mis llamadas a la API de JavaScript, porque bueno, está en la misma aplicación. Solo puedo usar el [authorize]atributo en un punto final de API, cuando un usuario no está conectado, no obtendrá los datos.

Además, cuando se trata de carritos de compras y desea almacenar un carrito de compras de usuarios en una sesión (mientras no está conectado), también debe tener esto en su API si agrega / elimina productos a través de su código javascript. Esto seguramente hará que su API tenga estado, pero también reducirá la complejidad en su MVC-API.

Steven de SimpleInjector (marco de IoC) aconseja dos proyectos separados: ¿Cuál es la diferencia entre DependencyResolver.SetResolver y HttpConfiguration.DependencyResolver en WebAPI?

Recientemente hice casi lo mismo: comencé con un nuevo proyecto de aplicación web MVC 4 eligiendo la plantilla de API web en VS2012.

Esto creará una API web alojada en la misma aplicación que MVC.

Quería mover ApiControllers a un proyecto de biblioteca de clases separado. Esto fue bastante fácil pero la solución estaba un poco oculta.

En AssemblyInfo.cs del proyecto MVC 4, agregue una línea de código similar

[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]

Ahora necesita la clase LibraryRegistrator (no dude en nombrarla como sea)

public class LibraryRegistrator
    {
        public static void Register()
        {
            BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
        }
    }

En el proyecto MVC 4 también agregue una referencia a la biblioteca Api.

Ahora puede agregar controladores Api a su propia biblioteca de clases separada (yourown.dll).

Incluso si su proyecto es tan complejo como para justificar dos "interfaces", entonces solo consideraría dividir webapi en un proyecto separado como último recurso. Tendrá dolores de cabeza de implementación y sería difícil para un novato comprender la estructura de su solución. Sin mencionar los problemas de enrutamiento.

Mi objetivo es mantener el espacio de nombres system.web aislado en una "capa de presentación". A pesar de que webapi no es de presentación , sigue siendo parte de la interfaz de su aplicación. Siempre que mantenga la lógica en su dominio y no en sus controladores, no debería tener demasiados problemas. Además, no olvide hacer uso de las áreas.

Además de configurar la DLL separada para Web.Api.

Sólo una sugerencia:

1. Crea el proyecto
2. Nugget WebActivatorEx

3. Cree un método de clase para ser llamado en app_start

   [ensamblado: WebActivatorEx.PostApplicationStartMethod (typeof (API.AppWebActivator), "Start")]

   [ensamblado: WebActivatorEx.ApplicationShutdownMethod (typeof (API.AppWebActivator), "Shutdown")]

4. Registrar una ruta web.api dentro del método de inicio

   public static void Start () {GlobalConfiguration.Configure (WebApiConfig.Register); }

5. Haga referencia al proyecto al proyecto web. para activar el método de inicio.

Espero que esto ayude.

Intenté dividir los controladores de API en un nuevo proyecto. Todo lo que he hecho es crear un nuevo proyecto de biblioteca, moví los controladores dentro de la carpeta llamada API. Luego agregó la referencia del proyecto de la biblioteca al proyecto MVC.

La configuración de webAPI se deja en el propio proyecto MVC. Funciona bien.