Fetch errorinternal server error swagger v1 swagger json

I was working with some ASP.NET WebApi code and needed to test something using the Swagger UI. Usually, it’s just a matter of starting the project and going to your /swagger directory. Unfortunately, in this case, I went to my swagger URL and got an error saying “Failed to load API definition — Fetch error — Internal Server Error /swagger/v1/swagger.json.” How do you fix this error?

I knew that it used to work but I’d just updated about a half zillion things in my code including upgrading to .NET Core 5 so I wasn’t really sure what broke it. I assumed the worst.

The dev tools in Edge was showing me that it was trying to access swagger.json but it was getting an HTTP 500 error. My guess was that I had a configuration problem in Startup.cs and that the swagger.json file either wasn’t being generated or it was in the wrong place. I checked a bunch of stuff and didn’t find anything.

I eventually started to figure out what was going wrong when I opened that call to swagger.json in its own tab.

The actual error message says that there’s an “ambiguous HTTP method for action”. I wasn’t really sure what that meant by helpfully the error message pointed me at the WebApi endpoint action that was causing the problem. Rather than being a problem with some kind of swagger config, the error was coming from the code that I’d just been working on.

Swashbuckle.AspNetCore.SwaggerGen.SwaggerGeneratorException: Ambiguous HTTP method for action - SwaggerError.WebApi.Controllers.WeatherForecastController.Overview (SwaggerError.WebApi). Actions require an explicit HttpMethod binding for Swagger/OpenAPI 3.0
   at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GenerateOperations(IEnumerable`1 apiDescriptions, SchemaRepository schemaRepository)
   at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GeneratePaths(IEnumerable`1 apiDescriptions, SchemaRepository schemaRepository)
   at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GetSwagger(String documentName, String host, String basePath)
   at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

Here’s the code that’s causing the problem:

[ApiController]
[Route("[controller]")]
public class WeatherForecastController : ControllerBase
{
    [Route("/[controller]/[action]/{id}")]
    public ActionResult Overview(int? id)
    {
        return Ok(id);
    }
}

Looks pretty ordinary, right? Nothing to exciting here. So what’s broken? What’s “ambiguous” about this? It’s missing the HttpGet attribute.

[ApiController]
[Route("[controller]")]
public class WeatherForecastController : ControllerBase
{
    [HttpGet]
    [Route("/[controller]/[action]/{id}")]
    public ActionResult Overview(int? id)
    {
        return Ok(id);
    }
}

As soon as I added that missing [HttpGet] attribute, the Swagger UI was working again.

Summary

In short, the problem was a problem in my code. I’d assumed that my WebApi controller action would default to HTTP GET but it seems that that doesn’t agree with Swagger. As soon as I added that missing attribute, everything was fine.

I hope this helps.

-Ben

— Looking for help on your .NET Core projects? Want some guidance on how to get going with Azure DevOps or GitHub Actions? Need a Scrum coach to help your teams get over a delivery slump? We can help. Drop us a line at info@benday.com.

WebApi Core / Swagger: “failed to load API definition” error

I was working with some ASP.NET WebApi code and needed to test something using the Swagger UI. Usually, it’s just a matter of starting the project and going to your /swagger directory. Unfortunately, in this case, I went to my swagger URL and got an error saying “Failed to load API definition — Fetch error — Internal Server Error /swagger/v1/swagger.json.” How do you fix this error?

The Swagger UI error

I knew that it used to work but I’d just updated about a half zillion things in my code including upgrading to .NET Core 5 so I wasn’t really sure what broke it. I assumed the worst.

The dev tools in Edge was showing me that it was trying to access swagger.json but it was getting an HTTP 500 error. My guess was that I had a configuration problem in Startup.cs and that the swagger.json file either wasn’t being generated or it was in the wrong place. I checked a bunch of stuff and didn’t find anything.

The call to get swagger.json was returning HTTP 500

I eventually started to figure out what was going wrong when I opened that call to swagger.json in its own tab.

The error message on that HTTP 500 to swagger.json

The actual error message says that there’s an “ambiguous HTTP method for action”. I wasn’t really sure what that meant by helpfully the error message pointed me at the WebApi endpoint action that was causing the problem. Rather than being a problem with some kind of swagger config, the error was coming from the code that I’d just been working on.

Here’s the code that’s causing the problem:

Looks pretty ordinary, right? Nothing to exciting here. So what’s broken? What’s “ambiguous” about this? It’s missing the HttpGet attribute.

As soon as I added that missing [HttpGet] attribute, the Swagger UI was working again.

Summary

In short, the problem was a problem in my code. I’d assumed that my WebApi controller action would default to HTTP GET but it seems that that doesn’t agree with Swagger. As soon as I added that missing attribute, everything was fine.

Источник

ProgrammerAH

Programmer Guide, Tips and Tutorial

How to Solve Internal Server Error: /swagger/v1/swagger.json

Sometimes, when running swagger, it will cause“ Internal Server Error /swagger/v1/swagger.json ” Wrong.

Here are my solutions:

1. First look at the console and check the reason. The reason is: ambiguous HTTP method for action, which is translated as “ambiguous HTTP operation method”. It is estimated that a brother did not indicate the HTTP method when submitting the code.

2. Search all public methods in the controller. In the search result window, press ↓ on the keyboard and ↑ Button to quickly switch to search. Finally, it is found that the method is written in public and changed to private.

Ambiguous HTTP method for action, translated as “ambiguous HTTP operation method”.

There may be no HTTP method written, such as [httpget], [httppost], add to the method.

It may also be caused by writing some methods that should have been private to public.

Источник

Fetch error Internal Server Error doc.json #678

Describe the bug
I’ve followed the procedure to use swag with a gin application. I’ve also checked the example implementation from the source. But, unfortunately facing the error. I’m attaching 2 screenshots of the problem.

To Reproduce
Steps to reproduce the behavior:

1. go get -u github.com/swaggo/swag/cmd/swag
2. Follow the steps to use it with gin application.
3. After doing swag init , I faced a problem like swag not found on a mac. So I did export PATH=$PATH:$HOME/go/bin which fixed the error and generated required files in ./docs dir.
4. After running the application, I used http://localhost:8888/swagger/index.html as url and getting this error.

Expected behavior
I wanted to display the API docs.

Screenshots

Your swag version
1.6.5

Your go version
1.12.0

Desktop (please complete the following information):

• OS: MacOS Calatila 10.15.3
• Browser: [Safari, Chrome]
• Version: [13.0.5, 80.0.3987.163]

Additional context
I’ve tried several times to find out the issue but seems not yet registered swag swag is not registered.

The text was updated successfully, but these errors were encountered:

Источник

TheCodeBuzz

Best Practices for Software Development

Failed to load API definition (undefined /swagger/v1/swagger.json)

Error: Failed to load API definition Fetch error in Swagger(undefined /swagger/v1/swagger.json)

Issue Description

Swagger Open API documentation gives the below error in .NET Core API etc.

“Failed to load API definition. Fetch error undefined /swagger/v1/swagger.json”

It is also observed that Swagger API documentation/description works on ‘localhost’ i.e locally but when it runs in publish mode i.e hosted on IIS or Cloud Server, produces the error like “Failed to load API definition” with undefined/swagger/v1/swagger.json error.

Resolution

Before applying this fix, I would recommend you to validate the swagger implementation with the below article,

Please make sure you verify the below points steps,

Resolution 1

Swagger Document is defined with proper Title and Version details, as both are required parameters.

Resolution 2

Please make sure the API doesn’t contain any conflicting action. Conflicting action could be using the same routes. To be on the safer side, you can very much use the below flag to control that behavior,

Resolution 3

Please make sure all controller methods are attributed with proper HTTP attributes Example- HttpGET or HttpPost etc. Missing this attribute could cause the error.

If the issue still persists then please apply the below fix to resolve the issue.

Resolution 5

Please check if the hosting server allows CORS request processing. Also, its important swagger UI-related resources like CSS or stylesheets are accessible from your server.

Resolution 6

Please, note that Swagger JSON will be exposed at the following route as per default behavior.

If you are using a custom route or prefix, then the route MUST include the <documentName> parameter.

To fix the issue, please update the UseSwagger() as below,

The above changes also need to be reflected in SwaggerUI middleware. Please update the UseSwaggerUI method will be as follows,

Please note that in Swaggerendpoint() method ‘documentName’ value is cases sensitive.

In fact, documentName is case sensitive anywhere else if referenced.

This documentName is generally a Group Name associated with API version

Example: It won’t work for V1 but works for v1.

If using RoutePrefix in API then it can be defined as below,

Example only if using RoutePrefix,

Here MyTestService is my service name.

Please see below the complete implementation,

Finally, Swagger runs successfully locally and in any hosting environment like IIS or Azure Cloud, etc.

For any other issues, please use google chrome dev tools(FUN F12) or Edge Developer tools to verify the exact error causing the issue. Please verify Console and Network tab to validate the exact erros.

Other References:

Add swagger to ASP.NET Core API in simple 2-3 steps:

Did I miss anything else in these resolution steps?

Did the above steps resolve your issue? Please sound off your comments below!

Please bookmark this page and share it with your friends. Please Subscribe to the blog to get a notification on freshly published best practices and guidelines for software design and development.

Источник

Swagger error in ASP.NET Core 5 MVC API Web App (MVC)

I created an ASP.NET Core 5 Web App for “API” (similar to MVC) with the OpenAPI (aka Swagger) option turned on.

To note: I have nearly 2 decades experience with .NET but this is my first real-world dive into .NET Core/5, so I’m skipping the whole “learning from first principals” and figuring it out as I go off the back of what I already know.
In this case I’m setting up a new project to move some part of an existing ASP.NET 4.6 MVC app into it.

It was all working fine until I wanted to add an OnActionExecuting() override to the Controller, from the IActionFilter interface.
Once I added the interface and the 2 required method the calls to the actual controller, calling the endpoints worked fine. But F5 debug runs of the project, which loaded the https://localhost:xxxxx/swagger/index.html page, would produce the error:

Failed to load API definition.

Errors

Fetch errorundefined /swagger/v1/swagger.json

Which in typical 3rd party framework fashion is fucking useless for consuming and gives use no useful information to work with.

So off to StackOverflow I go.

After a search for OnActionExecuting Fetch errorundefined /swagger/v1/swagger.json I came across this page: https://stackoverflow.com/questions/48450262/asp-net-core-swashbuckle-not-creating-swagger-json-file, specifically the answer https://stackoverflow.com/a/53632914/115704 which mentioned [NoAction] . Things then clicked for me.

The [NoAction] attribute on the 2 interface methods didn’t work for me, but after a bit more searching I found [NonAction] and which solved the problem.

Then I was back up and working with Swagger again.

Screenshots

Code before the fix

(Noting the [NonAction] is not impmented)

The error from Swagger

Honestly, how fucking useless is this an an error? About as good as the classic “an unexpected error occurred” (to which I always exclaim: “no shit, Sherlock!” Like any developer actually expects an error).

Code after the Fix

[NonAction] attributes have been implemented.

Swagger after the fix

And look, Swagger works again.

At the end of the day this was a couple of hours of my night lost.

Partly my fault for implementing a new version of .NET without doing the obligatory 40 hours of training. Also partly Swaggers fault because, well, it pissed me off for not giving a more detailed error message, especially in a development environment.

Источник

March 4th, 2020

Few months ago we announced an experimental release of OData for ASP.NET Core 3.1, and for those who could move forward with their applications without leveraging endpoint routing, the release was considered final, although not ideal.

But for those who have existing APIs or were planning to develop new APIs leveraging endpoint routing, the OData 7.3.0 release didn’t quiet meet their expectations without having to disable endpoint routing.

Understandably this was quite a trade off between leveraging the capabilities of endpoints routing versus being able to use OData. Therefore in the past couple of months the OData team in coordination with ASP.NET team have worked together to achieve the desired compatibility between OData and Endpoint Routing to work seamlessly and offer the best capabilities of both worlds to our libraries consumers.

Today, we announce that this effort is over! OData release of 7.4.0 now allows using Endpoint Routing, which brings in a whole new spectrum of capabilities to take your APIs to the next level with the least amount of effort possible.

Getting Started

To fully bring this into action, we are going to follow the Entity Data Model (EDM) approach, which we have explored previously by disabling Endpoint Routing, so let’s get started.

We are going to create an ASP.NET Core Application from scratch as follows:

Since the API template we are going to select already comes with an endpoint to return a list of weather forecasts, let’s name our project WeatherAPI, with ASP.NET Core 3.1 as a project configuration as follows:

Installing OData 7.4.0 (Beta)

Now that we have created a new project, let’s go ahead and install the latest release of OData with version 7.4.0 by either using PowerShell command as follows:

Install-Package Microsoft.AspNetCore.OData -Version 7.4.0-beta

You can also navigate to the Nuget Package Manager as follows:

Startup Setup

Now that we have the latest version of OData installed, and an existing controller for weather forecasts, let’s go ahead and setup our startup.cs file as follows:

using System.Linq;
using Microsoft.AspNet.OData.Builder;
using Microsoft.AspNet.OData.Extensions;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.OData.Edm;

namespace WeatherAPI
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddControllers();
            services.AddOData();
        }

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseHttpsRedirection();

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();
                endpoints.Select().Filter().OrderBy().Count().MaxTop(10);
                endpoints.MapODataRoute("odata", "odata", GetEdmModel());
            });
        }

        private IEdmModel GetEdmModel()
        {
            var odataBuilder = new ODataConventionModelBuilder();
            odataBuilder.EntitySet<WeatherForecast>("WeatherForecast");

            return odataBuilder.GetEdmModel();
        }
    }
}

As you can see in the code above, we didn’t have to disable EndpointRouting as we used to do in the past in the ConfigureServices method, you will also notice in the Configure method has all OData configurations as usual referencing creating an entity data model with whatever prefix we choose, in our case here we set it to odata but you can change that to virtually anything you want, including api.

Weather Forecast Model

Before you run your API, you will need to do a slight change to the demo WeatherForecast model that comes in with the API template, which is adding a key to it, otherwise OData wouldn’t know how to operate on a keyless model, so we are going to add an Id of type GUID to the model, and this is how the WeatherForecast model would look like:

    public class WeatherForecast
    {
        public Guid Id { get; set; }
        public DateTime Date { get; set; }
        public int TemperatureC { get; set; }
        public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
        public string Summary { get; set; }
    }

Weather Forecast Controller

We had to enable OData querying on the weather forecast endpoint while removing all the other unnecessary annotations, this is how our controller looks like:

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.AspNet.OData;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Logging;

namespace WeatherAPI.Controllers
{
    public class WeatherForecastController : ControllerBase
    {
        private static readonly string[] Summaries = new[]
        {
            "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
        };

        [EnableQuery]
        public IEnumerable<WeatherForecast> Get()
        {
            var rng = new Random();
            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Id = Guid.NewGuid(),
                Date = DateTime.Now.AddDays(index),
                TemperatureC = rng.Next(-20, 55),
                Summary = Summaries[rng.Next(Summaries.Length)]
            })
            .ToArray();
        }
    }
}

Hit Run

Now that we have everything in place, let’s run our API and hit our OData endpoint with an HTTP GET request as follows:

https://localhost:44344/odata/weatherforecast

The following result should be returned:

{
  "@odata.context": "https://localhost:44344/odata/$metadata#WeatherForecast",
  "value": [
    {
      "Id": "66b86d0d-375f-4133-afb4-82b44f7f2e79",
      "Date": "2020-03-02T23:07:52.4084956-08:00",
      "TemperatureC": 23,
      "Summary": "Mild"
    },
    {
      "Id": "d534a764-4fb8-4f49-96c5-8f09987a61d8",
      "Date": "2020-03-03T23:07:52.4085408-08:00",
      "TemperatureC": 9,
      "Summary": "Balmy"
    },
    {
      "Id": "07583c78-b2f5-4119-acdb-50511ac02e8a",
      "Date": "2020-03-04T23:07:52.4085416-08:00",
      "TemperatureC": -15,
      "Summary": "Hot"
    },
    {
      "Id": "05810360-d1fb-4f89-be18-2b8ddc75beff",
      "Date": "2020-03-05T23:07:52.4085421-08:00",
      "TemperatureC": 9,
      "Summary": "Hot"
    },
    {
      "Id": "35b23b1a-4803-4c3e-aebc-ced17807b1e1",
      "Date": "2020-03-06T23:07:52.4085426-08:00",
      "TemperatureC": 16,
      "Summary": "Hot"
    }
  ]
}

You can now try the regular operations of $select, $orderby, $filter, $count and $top on your data and examine the functionality yourself.

Non-Edm Approach

If you decide to go the non-Edm route, you will need to install an additional Nuget package to resolve a Json formatting issue as follows:

First of all install Microsoft.AspNetCore.Mvc.NewtonsoftJson package by running the following PowerShell command:

Install-Package Microsoft.AspNetCore.Mvc.NewtonsoftJson -Version 3.1.2

You can also navigate for the package using Nuget Package manager as we did above.

Secondly, you will need to modify your ConfigureService in your Startup.cs file to enable the Json formatting extension method as follows:

using System.Linq;
using Microsoft.AspNet.OData.Extensions;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

namespace WeatherAPI
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddControllers().AddNewtonsoftJson();
            services.AddOData();
        }

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseHttpsRedirection();

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();
                endpoints.EnableDependencyInjection();
                endpoints.Select().Filter().OrderBy().Count().MaxTop(10);
            });
        }
    }
}

Notice that we added AddNewtonsoftJson() to resolve the formatting issue with $select, we have also removed the MapODataRoute(..) and added EnableDependencyInjection() instead.

With that, we have added back the weather forecast controller [ApiController] and [Route] annotations in addition to [HttpGet] as follows:

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.AspNet.OData;
using Microsoft.AspNetCore.Mvc;

namespace WeatherAPI.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class WeatherForecastController : ControllerBase
    {
        private static readonly string[] Summaries = new[]
        {
            "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
        };

        [HttpGet]
        [EnableQuery]
        public IEnumerable<WeatherForecast> Get()
        {
            var rng = new Random();
            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Id = Guid.NewGuid(),
                Date = DateTime.Now.AddDays(index),
                TemperatureC = rng.Next(-20, 55),
                Summary = Summaries[rng.Next(Summaries.Length)]
            })
            .ToArray();
        }
    }
}

Now, run your API and try all the capabilities of OData with your ASP.NET Core 3.1 API including Endpoint Routing.

Final Notes

1. The OData team will continue to address all the issues opened on the public github repo based on their priority.
2. We are always open to feedback from the community, and we hope to get the community’s support on some of our public repos to keep OData and it’s client libraries running.
3. With this current implementation of OData you can now enable Swagger easily on your API without any issues, here’s an example
4. You can clone the example we used in this article from this repo here to try it for yourself.
5. The final release of OData 7.4.0 library should be released within two weeks from the time this article was published.