2011-03-14 21 views
17

Soy nuevo en el desarrollo de servicios WCF REST Full y estoy buscando información útil y sus comentarios sobre el uso de webHttpBinding en comparación con la nueva WCF Web API http://wcf.codeplex.com/.WCF Web Api vs WebHttpBinding

Lo que estoy buscando es conocer las deficiencias de webHttpBinding y, por lo tanto, por qué utilizar la nueva API web y especialmente qué problemas resuelve la nueva API. Si me pudieras señalar algunas publicaciones de blog comparando ambas o simplemente hablando sobre los problemas al usar webHttpBinding, te agradecería. Gracias de antemano.

Respuesta

21

Principales deficiencias Yo diría que el webhttpbinding hace que sea difícil manejar las preocupaciones específicas de HTTP. Funciona muy bien si todo lo que hace es pasar un objeto a través de HTTP que se serializa en XML o JSON y que puede ser transportado en diferentes formatos.

HTTP es mucho más que un simple protocolo de transporte para XML y JSON, es un protocolo de capa de aplicación con una rica semántica. Web API está dirigida específicamente a personas que desean construir sistemas a través de HTTP que aprovechen completamente la riqueza de HTTP.

  1. La API web admite que HTTP Resources puede tener una multitud de representaciones basadas en las necesidades de diferentes clientes. Un extremo del espectro podría ser un navegador tonto que solo habla con un servicio usando una publicación codificada en url de Form y un GET, mientras que el otro podría ser un cliente más rico que usa Atom/OData o un tipo de medios basado en hipermedia.

  2. La API web admite que hay otras preocupaciones específicas de HTTP como conneg, etags, etc. que permiten aprovechar mejor los servidores web intermediarios.

  3. La API web está diseñada con más capacidad de prueba en mente, por lo que puede abordar el trabajo con mensajes HTTP u otras inquietudes de una forma más comprobable.

  4. La API web tiene una historia de configuración más simplificada.

Puede leer más sobre el fundamento aquí: http://blogs.msdn.com/b/endpoint/archive/2010/11/01/wcf-web-apis-http-your-way.aspx

+0

Desde un Administrador de programas de Microsoft, realmente suena como "Si está haciendo HTTP, puede olvidarse de WCF" para mí. ¿Es esto lo que estás diciendo? ¿Cuál es el futuro de WCF en el área HTTP? –

+0

WCF Web API es WCF :-) Lo que estamos diciendo es que WCF Web API es mucho más adecuado para trabajar con HTTP/construir servicios RESTful que WCF 4.0/webhttbinding. –

2

La API web es algo así como el futuro posible del desarrollo REST en WCF. Es solo una vista previa que puede cambiar significativamente antes de la versión final (probablemente en la próxima versión de .NET Framework). Por lo tanto, si desea construir el servicio REST de producción, debe usar webHttpBinding.

La información disponible sobre Web Api se puede encontrar, por ejemplo, en .NET Connected Framework team's blog y en el sitio que usted mencionó. Es simplificación y extensión de la API REST actual.

+0

Web API se enviará fuera de banda en .NET 4.0 similar a MVC. Puede encontrarlo en wcf.codeplex.com. –

3

La diferencia más significativa para mí es el cambio en el modelo de programación. Ya no se escriben 'servicios' que exponen 'operaciones' vinculadas a expresiones idiomáticas HTTP (GET, POST, etc.). Con las API web, crea 'recursos' (POCO) con los que sus clientes pueden interactuar.

Las API web parecen ser mejores en el manejo de varios tipos de medios personalizados (como imágenes PNG, por ejemplo).

Por último, pero no menos importante, las API web son mucho más adecuadas para las pruebas automatizadas. Por ejemplo, ya no tiene que usar clases de contexto estáticas para acceder a los conceptos de HTTP, como los códigos de respuesta. Utiliza las clases de solicitud y respuesta de POCO que se pueden instanciar fácilmente en pruebas automatizadas utilizando el operador new() de estilo antiguo.

Estoy de acuerdo con Ladislav en que las API web son solo una vista previa ahora y la creación de una aplicación en la parte superior puede ser arriesgada y prohibida por medio del acuerdo de licencia (pero no lo he comprobado).

¿Has considerado el OpenRasta de @ serialseb? Es estable y ofrece un modelo de programación muy agradable para construir servicios RESTful.

0

Web API proporciona una API basada en REST HTTP ambiente. La API web utiliza los patrones de MVC y les resultará muy familiar a los desarrolladores de ASP.NET MVC. Web API puede aprovechar las capacidades de HTTP como un protocolo de capa de aplicación, devolviendo recursos en múltiples representaciones (XML, JSON, HTML, etc.) de acuerdo con los encabezados de solicitud del cliente.

Por otro lado, WCF webHttpBinding usa los patrones de WCF, y va a atraer más al desarrollador de WCF - ServiceContracts, OperationContracts, integral (o sobrepeso, dependiendo de cómo lo mires, archivo de configuración), capacidad de self -host fuera de IIS.

Una de las cosas que me gusta de Web API es la capacidad de usar tipos dinámicos para escapar de las limitaciones del sistema de tipos. También me gusta el comportamiento de excepción predeterminado en la API web: contraste WCF webHttpBinding donde, de forma predeterminada, las excepciones aparecen como HTTP 500 + una carga útil HTML (yuk!).

Es bueno tener la opción entre dos excelentes tecnologías aquí. No describiría Web API como 'más nuevo' o 'mejor' que WCF, ya que esto implica que es una tecnología de reemplazo y que WCF webHttpBinding es heredado, lo cual no creo que sea cierto.

Elegí usar WCF webHttpBinding recientemente para exponer una API JSON para un servicio WCF SOAP existente. Creo que fue una buena elección porque encajaba con ese estilo de esa solución existente y minimizaba la cantidad de cambios requeridos.