todos. Estoy tratando de documentar un WebApi 2 uso de Swashbuckle paquete.

Todo funciona muy bien si la API se ejecuta por sí misma, es decir, localhost/api/swagger me lleva a la interfaz de usuario y localhost/api/swagger/docs/v1 a json.

Sin embargo, la producción de la aplicación inicializa este mismo Webapi proyecto mediante la ejecución de webapiconfig método de este proyecto global.asax.cs en otro – ahora en la web del proyecto (la principal de la aplicación). Por lo que la api de url se parece a localhost/web/api en lugar de localhost/api.

Ahora swashbuckle no es así en absoluto.

  • localhost/api/swagger genera el error no se puede cargar
    ‘API.WebApiApplication’, bueno, por supuesto
  • localhost/web/swagger = 404
  • localhost/web/api/swagger = 404

Traté de mirar a todas partes, pero todos los que he encontrado es la solución.

c.RootUrl(req => req.RequestUri.GetLeftPart(UriPartial.Authority) + VirtualPathUtility.ToAbsolute("~/").TrimEnd('/'));

Desgraciadamente no funciona, ahora tal vez debería y sólo tengo que cambiar algo, pero yo no sé ni qué es exactamente esta propiedad de espera y lo que se debe establecer.

Puede ser no aplicable – tal vez el programa de instalación hemos requiere algo más, o algunos swashbuckle cambios en el código.

Agradezco cualquier ayuda que pueda ofrecer. Yo realmente empezando a gustar arrogancia (y swashbuckle) para el resto de la documentación.

OriginalEl autor Dmitriy | 2015-05-01

1 Comentario

  1. 15

    Para Swashbuckle 5.x:

    Esto parece ser establecido por un método de extensión de httpConfiguration llamado EnableSwagger. Swashbuckle 5.x la migración léame señala que este reemplaza SwaggerSpecConfig. SwaggerDocConfig RootUrl() específicamente reemplaza ResolveBasePathUsing() de 4.x.

    Esta prácticamente funciona de la misma manera como lo hacía antes, parece que el cambio más importante fue que se cambió de nombre y pasó a SwaggerDocConfig:

    public void RootUrl(Func<HttpRequestMessage, string> rootUrlResolver)

    Un ejemplo de la léame, ajustado por razones de brevedad:

    string myCustomBasePath = @"http://mycustombasepath.com";
    
    httpConfiguration
        .EnableSwagger(c =>
            {
                c.RootUrl(req => myCustomBasePath);
    
                //The rest of your additional metadata goes here
            });

    Para Swashbuckle 4.x:

    Uso SwaggerSpecConfig ResolveBasePathUsing y tiene su lambda leer su extremo.

    ResolveBasePathUsing:

    public SwaggerSpecConfig ResolveBasePathUsing(Func<HttpRequestMessage, string> basePathResolver);

    Mi API está detrás de un equilibrador de carga, y esto fue una útil solución para proporcionar una dirección base. He aquí un ejemplo tonto para usar ResolveBasePathUsing para resolver la ruta de acceso con una conocida ruta de acceso base.

    string myCustomBasePath = @"http://mycustombasepath.com";
    
    SwaggerSpecConfig.Customize(c =>
    {
        c.ResolveBasePathUsing((req) => myCustomBasePath);
    }

    He codificado el extremo para mayor claridad, pero se puede definir en cualquier lugar. Usted puede incluso utilizar el objeto request para intentar la limpieza de su uri de la solicitud a punto de a /web/api en lugar de /api.

    El desarrollador comentó en esta solución en GitHub el año pasado:

    La lambda lleva la corriente HttpRequest (es decir, la solicitud de un determinado
    Swagger ApiDeclaration) y debe devolver una cadena para ser utilizado como el
    baseUrl para su Api. Para el equilibrio de carga de aplicaciones, esto debería devolver el equilibrador de carga ruta.

    La implementación predeterminada es la siguiente:

    (req) => req.RequestUri.GetLeftPart(UriPartial.Authority) +  req.GetConfiguration().VirtualPathRoot.TrimEnd('/');

    Volver a las rutas relativas, la Arrogancia especificación requiere rutas de acceso absolutas porque
    la dirección URL en la que la Arrogancia es la que se sirve no tiene que ser la URL de
    la real en el API.

    La lambda se pasa un HttpRequestMessage ejemplo … usted debe ser capaz de utilizar este para llegar a la RequestUri etc. Otra opción, podría poner el nombre de host en su web.config y tienen la lambda acabo de leer que a partir de ahí.

    Este github artículo fue el primero que leí, el último comentario es exactamente donde tengo el código que puse en mi pregunta. No trabajo. Me encantaría probar de la manera que usted describe, porque al menos ahora veo lo que se espera como un valor. Pero el código que proporcionó no funciona como es. VS queja acerca de SwaggerSpecConfig como indefinido. Puede proporcionar el código completo y una versión de swashbuckle que este código funciona? Por favor.
    Ver mis actualizaciones. Estoy usando Swashbuckle.Núcleo 4 con algunos no relacionados extensiones. Mirando Swashbuckle 5, parece que esta función de dirección url base se ha limpiado un poco y más fácil de encontrar y utilizar. No te preocupes por SwaggerSpecConfig y ResolveBasePathUsing si usted está usando 5, ha sido reemplazado con el httpConfiguration método de extensión EnableSwagger. Perdón por la confusión, no he necesarios para actualizar a 5 sin embargo, y esta parecía una muy similar problema que he tenido antes. 🙂
    Por desgracia, no funciona. Estoy empezando a pensar que podría ser un error. Traté de poner todo en la RootUrl localhost, localhost/web y localhost/web/api todavía genera 404 para mí.
    El sobre respuesta es correcta, el problema que estaba teniendo el swashbuckle fue instalado en la API. Una vez instalado en la Web del proyecto (y algunos URI reescritura cambiado) que comenzó a funcionar correctamente. Es complicado tener esta mezcla de rutas y de relativo y absoluto de los caminos. Pero ahora funciona. Gracias por su ayuda.

    OriginalEl autor Anthony Neace

Dejar respuesta

Please enter your comment!
Please enter your name here