and - web api rest c#

¿Cuál es la diferencia entre WCF Web API y ASP.NET Web API (7)

Aquí hay un buen artículo sobre Web Service, WCF y Web API http://goo.gl/T29A5B

Servicio web

Basado en SOAP y devuelve datos XML
Soporta solo protocolo HTTP. Solo es compatible con el protocolo HTTP.
Consumido por el cliente que puede entender xml SOAP Services.
Puede alojar en IIS. Se puede hospedar solo en IIS.
Fácil de aprender y entender

WCF

Basado en SOAP y devuelve datos XML. SOAP es una gran comparación, luego JSON y su sobrecarga también en la red.
La versión mejorada de los servicios web admite múltiples protocolos como TCP, HTTP, HTTPS, Canalizaciones con nombre, MSMQ a través de la configuración.
Más confiable cuando tanto el cliente como el servidor tienen .Net.
Su implementación y configuración es compleja
Consumido por el cliente que puede entender xml SOAP Services.
Autohospedaje, IIS y uso de servicios de Windows.

API web (API web 2.0)

Diseñe específicamente para construir HTTP Restful Services en .Net Framework.
Web API fácil de leer y manejable como JSON.
Admite todas las características de HTTP como URls, solicitud / respuesta, encabezados, almacenamiento en caché y control de versiones.
La API web admite muchos verbos HTTP como GET, POST, PUT, DELETE, etc.
La API web no tiene estado.
La API web admite funciones MVC (controladores, resultados de acciones, enrutamiento, filtros, carpetas de modelos, contenedores IOC o inyección de dependencias)
La API web puede ser alojada por sí misma, alojada en la aplicación y en IIS.
OWIN (Interfaz Web Abierta para .NET) se usa para autohospedaje.

He trabajado un poco en el pasado con WCF WebAPI y realmente me han gustado muchas de sus funciones, solo estoy jugando con ASP.NET Web API en este momento y parece completamente diferente (IE completamente eliminado de WCF).

¿Alguien sabe qué características de WCF WebAPI están incluidas en ASP.NET 4 Web API?

El siguiente fragmento encontrado en esta página de MSDN resume bien este dilema.

Use WCF para crear servicios web confiables y seguros accesibles a través de una variedad de transportes. Use ASP.NET Web API para crear servicios basados en HTTP que sean accesibles desde una amplia variedad de clientes. Use ASP.NET Web API si está creando y diseñando nuevos servicios de estilo REST. Aunque WCF brinda cierto soporte para escribir servicios de estilo REST, el soporte para REST en ASP.NET Web API es más completo y todas las mejoras futuras de la característica REST se realizarán en ASP.NET Web API. Si tiene un servicio WCF existente y desea exponer puntos finales REST adicionales, use WCF y WebHttpBinding.

He hecho un poco más de lectura al respecto y encontré algunas páginas de personas de MS sobre esto:

http://wcf.codeplex.com/wikipage?title=How%20to%20Migrate%20from%20WCF%20Web%20API%20to%20ASP.NET%20Web%20API :

Las abstracciones de WCF Web API se asignan a ASP.NET Web API aproximadamente de la siguiente manera

WCF Web API -> API web de ASP.NET

Servicio -> Controlador de API web
Operación -> Acción
Contrato de servicio -> No aplicable
Punto final -> No aplicable
Plantillas URI -> Enrutamiento ASP.NET
Gestores de mensajes -> Mismo
Formateadores -> Mismo
Manejadores de operaciones -> Filtros, carpetas modelo

y http://wcf.codeplex.com/discussions/319671

La pila integrada admite las siguientes características:

Modelo moderno de programación HTTP
Soporte completo para enrutamiento ASP.NET
Negociación de contenido y formateadores personalizados
Encuadernación y validación del modelo
Filtros
Composición de la consulta
Prueba fácil de unidad
Inversión del control mejorada (IoC) mediante DependencyResolver
Configuración basada en código
Self-host

La API de ASP.net es ligera y tiene soporte REST. Es más adecuado para aplicaciones móviles. WCF está lleno de más opciones. Depende de la complejidad del sistema seleccionar uno de estos.

Parece que WCF de alguna manera está muriendo o al menos se está volviendo mucho menos importante de lo que se suponía que era, y por eso también tiene mucho menos esfuerzo de desarrollo puesto en su conjunto de características. Las nuevas características en WCF son más cosméticas.

WCF se diseñó como una forma independiente de transporte / protocolo para la comunicación entre procesos. Incluso la idea era la abstracción independiente, en su mayoría se basaba en la pila SOAP. Cuando WCF 3.5 trajo soporte para REST, fue casi invadido porque REST tiene que ver con la dependencia del transporte. El uso de una API independiente de transporte para admitir la comunicación entre procesos, que se realiza mediante el uso directo de las características de transporte, pareció inconveniente. Como resultado, MS lanzó por primera vez WCF Rest API Starter Kit, que nunca llegó a RTM, pero fue una vista previa de las características que luego se incluyeron en WCF 4 y finalmente en .NET 4.5 o WCF Web API. Debido a que REST depende del transporte y actualmente solo se usa con HTTP (incluso teóricamente es posible utilizar otro protocolo de transporte), la API se movió a la parte .NET que es más adecuada para el procesamiento HTTP: a ASP.NET MVC actualmente muy popular.

Por lo que he aprendido, Microsoft mencionó un poco la confusión aquí.

Supongo que usted sabe de lo que se trata WCF, este gran marco construido sobre XML para permitir al usuario crear servicios distribuidos con una amplia variedad de tecnologías (desde SOAP hasta REST y MSMQ, etc.).

Es difícil usarlo (al menos para mí) y requiere una gran cantidad de bootstrap para que funcione, y finalmente se dieron cuenta de esto y comenzaron a proporcionar alguna configuración predeterminada para servicios http simples (WCF REST starter kit anyone?). ASP.NET MVC estaba ganando impulso y algunas de las funciones que proporcionaba (por ejemplo, la coincidencia automática de argumentos) comenzaron a aparecer en WCF.

Ahora esa es la situación:

Anuncio: ¡WCF Web API ahora es ASP.NET Web API! API web ASP.NET lanzada con ASP.NET MVC 4 Beta. La WCF Web API y la compatibilidad con WCF para el contenido de jQuery en este sitio se eliminarán a fines de 2012.

http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api

Y eso es mejor que yo.

Estoy bastante seguro de que debería ser posible alojar asp.net mvc4 webapi encima de WCF (si alguna vez lo necesita), pero no puedo encontrar documentación que pueda demostrar que estoy en lo cierto (o equivocado).

ACTUALIZAR (no cabe como comentario): Espere, hay una enorme diferencia entre "mover un subconjunto de tecnología de comunicación de una biblioteca / marco a otro" y "reemplazar WCF". Personalmente creo que WCF fue diseñado para algún tipo de concepto de comunicación y tiene un diseño bastante bueno, pero la computación distribuida se está moviendo de alguna manera a soluciones nuevas (y más simples) (vea el SOAP rico en características frente al REST flexible y flexible, aunque muchas personas todavía usan REST de manera RPC), y creo que este tipo de patrones de programación encajan mejor en la arquitectura MVC que en WCF. Se hizo un esfuerzo para diseñar una forma simple de construir / consumir servicios web sobre WCF, pero eventualmente descubrieron que no era la solución correcta.

Sin mencionar que muchos desarrolladores ahora usan ASP.NET MVC y quieren hacer reposo de servicios web para su aplicación web, jugar con WCF es a menudo exagerado para este tipo de cosas, y lo he experimentado en mi propia piel.

Creo que el mecanismo de enrutamiento es increíble y es el camino correcto a seguir, y si te fijas bien, incluyeron una parte (con diferentes nombres y tipos, pero el patrón estaba allí) en WCF. Así que sí, creo que si la EM no descarta esa parte de WCF, deberíamos hacerlo. Para responder estrictamente, no, no creo que alguna vez encuentres WebGet / WebInvoke en asp.net mvc *, simplemente no encaja.

Sí, el auto-host es probablemente la única parte de WCF contenida en ASP.NET MVC4 en este momento.

WCF Web API se reemplaza por ASP.NET Web API, que toma características de WCF Web API y las combina con las características de ASPNet MVC. ASP.NET Web API es un nuevo marco (02/2012) para crear y consumir servicios HTTP y una plataforma para crear un servicio RESTful.

Aunque no está en la pregunta original, vale la pena señalar que WCF está vivo y bien y que su soporte REST sigue siendo útil cuando tiene servicios SOAP (WS- *) existentes que debe admitir pero desea agregar REST para llegar a más clientes.

Referencia