¿Por qué no hay soporte de tipo WSDL para Web Api?

Así que recién estoy comenzando con .Net WebApi y una cosa que estoy notando de inmediato es que no hay un Contrato que defina cómo se ve y se debe consumir la API (Solicitud / Respuestas de cada Acción), esto generalmente es en forma de un WSDL para WCF / Soap.

Me parece que esto es algo que sería muy valioso y haría la vida mucho más fácil para los consumidores de su API.

¿Hay alguna razón por la que no hay una? ¿Hay algún paradigma o principio de programación que desconozco? ¿Hay alguna manera de que pueda crear uno?

JABÓN, DESCANSO Y CREATIVIDAD POPULAR

SOAP necesita un documento de descripción como WSDL porque cada recurso se puede consumir con diferentes mensajes, no hay una definición en el protocolo sobre las restricciones a los posibles nombres / mensajes que puede manipular un recurso.

Por ejemplo, en SOAP, su servicio web que permite a los clientes manipular a un usuario puede exponer la operación que crea un usuario en muchos mensajes diferentes, como:

addUser
createUser
insertUser

Por supuesto, estos son solo algunos mensajes de muestra, porque he visto muchos nombres de métodos de servicios web divertidos. Hay personas realmente creativas por ahí.

Por otro lado, si está exponiendo su sistema subyacente usando una API web que realmente respeta los principios REST, el cliente solo necesita saber que tiene un recurso llamado Usuarios, porque hay un 99% de posibilidades de que pueda crear un usuario en este camino

POST /Users

Y esto ocurre para cada operación que desea exponer utilizando SOAP o una API web REST.

A pesar de ser un protocolo SOAP, que restringe lo que puede o no hacer, y REST es una arquitectura de estilo, que deja muchos puntos abiertos sobre cómo hacer las cosas. Hay esfuerzos para definir convenciones sobre cómo exponer y consumir las API web REST.

DESCRIBIR UN RESTO API WEB

En el campo de cómo describir un REST de API web, puedo citar Swagger . No es un intento de crear un WSDL como REST api web, pero es un buen intento de crear un estándar abierto para describir REST apis web.

Swagger es una especificación e implementación completa del marco para describir, producir, consumir y visualizar servicios web RESTful.

Utilizo mucho Swagger y realmente me encanta, principalmente porque la interfaz de usuario Swagger te permite generar una consola y documentación en vivo para tu API web.

Hay muchas implementaciones de Swagger para la mayoría de los lenguajes: C #, Java, Python, Ruby, etc.

Si está utilizando la API web ASP .NET, hay algunos proyectos para generar automáticamente la especificación Swagger, como Swagger.NET

GENERANDO CLIENTES A UN RESTO API WEB

Debido a que las restricciones de REST, como el conjunto limitado de verbos (GET, POST, PUT, DELETE, etc.) no es tan difícil generar una biblioteca de cliente en una API web REST.

Proyectos como WebApiProxy pueden generar fácilmente clientes con C # y Javascript.

CONVENIOS PARA EL RESTO API WEB

Para que nuestras vidas sean más fáciles como desarrolladores, es bueno definir algunas convenciones de cómo se comportará nuestro REST de la API web, el mejor esfuerzo que conozco en este campo es el muy bueno Apigee - Libro electrónico de diseño de API web . El libro electrónico no es un intento de crear una biblia o un mantra sobre cómo diseñar su API, sino más bien una colección de convenciones observadas en las API REST de la gran web, como Twitter, Facebook, Linkedin, Google, etc.

En pocas palabras, porque SOAP fue diseñado para ser autodescriptivo: un punto final SOAP generalmente incluye un wsdl que describe qué operaciones proporciona y cómo se ven los datos (por medio de XSD integrados) que cada operación toma y / o devuelve.
Debido a esta autodescripción, es posible que una aplicación como Visual Studio genere un proxy de servicio web para ella.

Además, existen varias extensiones de SOAP (las especificaciones WS- *) que permiten utilizar el cifrado o el comportamiento transaccional con SOAP. La idea es que puede usar SOAP como su ventanilla única para crear servicios web de nivel empresarial.

Por otra parte...

WebAPI está diseñado para proporcionar servicios REST. El formato de comunicación para REST suele ser JSON o xml simple, aunque realmente no importa, incluso podría ser texto sin formato. Los servicios REST siguen una filosofía completamente diferente: están destinados a ser livianos para que puedan ser fácilmente consumidos por los scripts del lado del cliente como parte de una solución AJAX o por dispositivos móviles.
Como tal, es necesario mantener el nivel de ceremonia al mínimo, incluida la autodescripción. Además, incluso si quisiera, la mayoría de los formatos de comunicación utilizados en los servicios REST (como JSON) no tienen una forma formal de describir sus contenidos de todos modos.

Resumiendo, se podría decir que los servicios web SOAP se usan generalmente para integrar soluciones (posiblemente dispares), mientras que los servicios REST son más adecuados para proporcionar comunicación entre partes de la misma solución.

Las API SOAP / WS- * y RESTful no son lo mismo. Si desea crear SOAP / WS- * API de soporte WSDL, la herramienta de elección en la pila de Microsoft es WCF, montada con una opción de enlace HTTP (hay opciones de enlace XML y JSON, XML es la opción de soporte WSDL).

En la práctica, consumir un WSDL desde un lenguaje o plataforma de implementación diferente ha sido problemático. WS- * capas de seguridad en la parte superior aún más.

Mi propia experiencia ha sido principalmente con .Net, Node, Java y PHP a este respecto, y puedo decir que cuando tienes plataformas que no tienen que definir los detalles de un tipo secundario, o usarán "Object" como el definición, se vuelve problemático por decir lo menos. Más allá de esto, en su mayor parte, nadie realmente comprende todo SOAP / WS- * confiando mucho en las herramientas para que funcione. Esta herramienta tiene muchos gastos generales, y los diferentes sistemas funcionan de manera diferente.

Estas son algunas de las razones por las cuales las personas buscaron probar implementaciones más simples. Los servicios REST (ala Web API) ofrecen puntos finales alrededor de objetos / estado. La idea es que es más fácil definir un conjunto de estructuras de objetos más simples representadas en formato JSON, y los puntos finales para usar contra estas estructuras que tratar de usar WSDL desde un entorno extraño que no funciona, luego tratar de profundizar y evitar el problema

Irónicamente, esta es una de las áreas en las que he usado Node mucho como servicio de traducción, simplemente porque era lo suficientemente flexible como para aceptar implementaciones sucias como cliente, y podía escribir clientes simples contra mi carga útil adaptada que funcionaba mejor. EX: C # obtiene texto JSON, que uso JSON.Net para convertirlo en una representación de objeto que definí que realmente funcionó cuando no pude usar una importación WSDL.

En la práctica esto sucede mucho.

Si bien muchas de las respuestas aquí son geniales, creo que la respuesta es MUCHO más simple: estás buscando la tecnología incorrecta para el trabajo.

Si está buscando construir un servicio SOAP, realmente debería apegarse a WCF. Todavía es un marco muy poderoso, Microsoft todavía lo está desarrollando activamente, no se hicieron anuncios para que pensemos que irá a ninguna parte en el futuro, y se hizo con esto en mente. La API web de ninguna manera reemplaza a WCF (aunque probablemente sea más moderno que WCF).

La API web solía ser parte de WCF, pero se trasladó a la familia ASP.NET exactamente PORQUE realmente no encajaba con las otras tecnologías WCF. La API web está mucho más preocupada con el uso de HTTP como protocolo de aplicación que como protocolo de transferencia. En la API web, los verbos HTTP son el rey, en WCF HTTP simplemente sirve para habilitar el protocolo SOAP.

No culpe a la API web por no dar la capacidad de hacer ciertas cosas para las que no fue creada.