Swashbuckle.aspnetcore: /swagger/v2/swagger.json results 500 error

Created on 29 Feb 2016  路  8Comments  路  Source: domaindrivendev/Swashbuckle.AspNetCore

I just made the simplest setup for my project, but for some reason it always returns 500 error when I'm trying to get swagger.json file.
This is what I always see when trying to access /swagger/ui/index.html page
http://screencast.com/t/uWxgYZEx

Most helpful comment

@SimonTouchtech - regardless of SB, if you don't decorate actions with an explicit [HttpXXX] attribute you're allowing it to be called with any of the HTTP verbs. Rather than second guessing which of the verbs you intend the operation to be called with, SB forces you to be explicit.

The same dilemma arises out of ambiguous model binding when you don't specify what part of the request (uri, header, body etc.) a parameter is populated from - any of them will work and so SB can't be sure which you intended.

Despite some criticism around SB forcing you to be explicit (see https://github.com/domaindrivendev/Ahoy/issues/47), I'm strongly against ambiguity in API contracts, to the extent I'm not willing to go out of my way to support it. At least that's my stance as of now :)

All 8 comments

If you navigate directly to the swagger.json endpoint, which is the request that's returning a 500, you should get more detailed error info

Unfortunately I'm getting no extra info, only blank screen.

I had no idea about this package and method.
Here is the stack trace that is displayed when trying to access the swagger.json

System.NotSupportedException: Unbounded HTTP verbs for path 'Api'. Are you missing an HttpMethodAttribute?
at Swashbuckle.SwaggerGen.DefaultSwaggerProvider.CreatePathItem(IEnumerable1 apiDescriptions, ISchemaRegistry schemaRegistry) at Swashbuckle.SwaggerGen.DefaultSwaggerProvider.<>c__DisplayClass4_0.<GetSwagger>b__4(IGrouping2 group)
at System.Linq.Enumerable.ToDictionaryTSource,TKey,TElement
at System.Linq.Enumerable.ToDictionaryTSource,TKey,TElement
at Swashbuckle.SwaggerGen.DefaultSwaggerProvider.GetSwagger(String apiVersion, String host, String basePath, String[] schemes)
at Swashbuckle.Application.SwaggerGenMiddleware.d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at Swashbuckle.Application.SwaggerUiMiddleware.d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at Swashbuckle.Application.RedirectMiddleware.d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at Microsoft.AspNet.Builder.RouterMiddleware.d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at Microsoft.ApplicationInsights.AspNet.ExceptionTrackingMiddleware.d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at Microsoft.ApplicationInsights.AspNet.RequestTrackingMiddleware.d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at Microsoft.AspNet.IISPlatformHandler.IISPlatformHandlerMiddleware.d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at Microsoft.AspNet.Diagnostics.DeveloperExceptionPageMiddleware.d__7.MoveNext()

I'm not sure of the exact reason this error occurs, but we were able to fix it by adding an HttpMethodAttribute, just like the error message says. I don't know the implementation details of Swashbuckle and if this requirement could be removed but simply add an [HttpGet] or [HttpPost] or whatever HTTP method you're using above your method and it should do the trick.

I don't know if this will help someone. But this is how I resolved the exact same issue:
https://github.com/domaindrivendev/Swashbuckle/issues/581#issuecomment-235053027

@SimonTouchtech - regardless of SB, if you don't decorate actions with an explicit [HttpXXX] attribute you're allowing it to be called with any of the HTTP verbs. Rather than second guessing which of the verbs you intend the operation to be called with, SB forces you to be explicit.

The same dilemma arises out of ambiguous model binding when you don't specify what part of the request (uri, header, body etc.) a parameter is populated from - any of them will work and so SB can't be sure which you intended.

Despite some criticism around SB forcing you to be explicit (see https://github.com/domaindrivendev/Ahoy/issues/47), I'm strongly against ambiguity in API contracts, to the extent I'm not willing to go out of my way to support it. At least that's my stance as of now :)

This highlighted where to look for the issue, thank you

Was this page helpful?
0 / 5 - 0 ratings