Today in this article, we will see a few resolution steps for errors “Swagger Failed to load API definition. Fetch error”

Issue Description

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

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

It is observed that Swagger API documentation/description when it runs in publish mode i.e. hosted on IIS or Cloud Server or other servers produces the error like “Failed to load API definition” with undefined/swagger/v1/swagger.json error.

Resolution – Failed To Load API Definition

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

• ASP.NET Core 3.1 or 6.0 – Add Swagger OpenAPI V3.0 specification documentation

Please make sure you verify the below points or steps,

The above steps might resolve your issue in any order depending on the type of issue you facing.

Resolution 1- Resolving Conflicting actions

Please make sure the API doesn’t contain any conflicting action. This is the most common cause of this issue.

Conflicting action could be using the same routes or the same HTTP verb abbreviations for GET, POST routes, etc.

To be on the safer side, you can very much use the below flag to control that behavior,

c.ResolveConflictingActions(x => x.First());

Resolution 2 – Missing HTTP Attributes

Please make sure all controller methods are attributed with proper HTTP attributes Example- [HttpGET] or [HttpPost] etc.

Any missing attribute accidentally on any such public method could cause the error.

If the issue persists then please apply the below Resolution – 5 to resolve the issue.

Resolution 3- CORS or CSP issues

Please check if the hosting server allows CORS request processing.

Also, it is important swaggers UI-related resources like CSS or stylesheets are accessible from your server.

Swagger accessing resources from external sites may be not accessible due to CSP issues as explained in this article.

This is a common issue on a cloud server where you may need to whitelist a few domains.

Resolution 4 – Title and Version in Swagger

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

Resolution 5 – Use the correct Swagger configuration

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,

app.UseSwagger(c =>
{  c.RouteTemplate = "<custom-name>/swagger/{documentName}/swagger.json";   }
);

Example,

 


c.RouteTemplate = "MyTestService/swagger/{documentName}/swagger.json";  

The above changes also need to be reflected in SwaggerUI middleware.

Please update the UseSwaggerUI method will be as follows,

app.UseSwaggerUI(c =>
             {
                 c.SwaggerEndpoint("/<custom-name>/swagger/v1/swagger.json", "TestService");
             });

Example:

 app.UseSwaggerUI(c =>
             {
          c.SwaggerEndpoint("/MyTestService/swagger/v1/swagger.json", "TestService");
             }); 

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,

c.RoutePrefix= "MyTestService/swagger"

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.

Resolution 6 – Other Issues?

For any other issues, please use your browser debug tools to verify for specific errors.

For example – Google Chrome Dev tools ( F12), or Edge Developer tools to verify the exact error causing the issue.

Please verify the Console -> Network tab to validate the exact error.

Other References:

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

• Swagger API Documentation in .NET Core 6 or 3.1

• API versioning support for Swagger/OpenAPI

Did I miss anything else in these resolution steps?

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

Happy Coding !!

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post Resolved: Swagger Failed to load API definition. Fetch error first appeared on TheCodeBuzz.

Today in this article, we will see how to do file/rolling file logging using Serilog in ASP.NET Core API application.

We shall be leveraging the DI( Dependency Injection) framework to inject the Serilog logger object into the API pipeline.

Today in this article, we will cover below aspects,

Logging in .NET 3.1 onwards framework is simplified further.

In the last article, we saw how to Enable Logging in ASP.NET Core using Built-in Providers.

We also discovered that the File/Rolling File logging provider is still not available through the framework and we need to rely on external solutions like Serilog.

Microsoft recommends using a third-party logger framework like a Serilog or NLog or Log4Net for other high-end logging requirements like Database or File/Rolling File logging.

In this post, we will understand, how to enable file/ rolling file logging in using Serilog and do customization to existing behavior using an example.

Getting started

Create an ASP.NET Core API using .NET Core 3.1 or .NET 6

Please add below NuGet Packages,

Please use the latest available version available for the ASP.NET Core version.

To set the Serilog log as a logging provider for logging purposes, please add below NuGet package,

PM> Install-Package Serilog.AspNetCore -Version 3.2.0

Note: Please use the latest Nuget version available

The above package will help to target Serilog as a logging provider.

Now hereafter depending on the type of provider support adding Serilog will help you log in to that source.

Examples. Console or File logging

Here below we will see how to enable File logging,

For Rolling File logging-

  Install-Package Serilog.Sinks.RollingFile -Version 3.3.0 

For Regular File logging-

Install-Package Serilog.Sinks.File

Or

Please install the above packages through Nuget Package Manager,

Update Main() method

Please update the Main method for adding the rolling file as shown in the below-highlighted code in the Program.cs

The main method in ASP.NET Core 3.1 and the above framework

Please create logger configuration as below,

//
public static void Main(string[] args)
        {

            Log.Logger = new LoggerConfiguration()
            .WriteTo.RollingFile("Thecodebuzz-log-{Date}.txt")
            .CreateLogger();
            CreateHostBuilder(args).Build().Run();

            Log.CloseAndFlush();
        }

Basic File Logging

For basic file, logging create the logger configuration as below (for both asp.net core 2.2 and 3.1)

 Log.Logger = new LoggerConfiguration()
            .WriteTo.File("Thecodebuzz-log-{Date}.txt")
            .CreateLogger();

Update Host Builder ASP.NET Core API Pipeline

Please update the CreateHostBuilder() method for Serilog as below,

public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                }).UseSerilog();

Now you are all set to use Serilog in ASP.NET Core!!

Let’s now log in to Controller using the regular ILogger Interface.

Here below controller uses the ILogger interface using dependency injection.

    //
    [Route("api/[controller]")]
    [ApiController]
    public class TestController : ControllerBase
    {
        private readonly ILogger _logger;

        public TestController(ILogger<TestController> logger)
        {
            _logger = logger;
        }
        // GET api/values
        [HttpGet("{id}")]
        public ActionResult<IEnumerable<string>> Get(int id)
        {
            _logger.LogInformation("Start : Getting item details for {ID}", id);

            List<string> list = new List<string>();
            list.Add("A");
            list.Add("B");

            _logger.LogInformation("Completed : Item details for {ID}", list);
            return list;
        }
    }

Once the code is executed the file will be created in the project directory and logging will be captured as shown below figure.

You can enable logging on any controller or any other layer of your API like the Business or domain layer easily. Also as shown above logging can be enabled on Startup.cs and Program.cs files as well.

Below is an example of file logging created by Serilog,

Please note the logging configuration will be used as-is from the default configuration i.e. specified in the apsetting.json.

CreateDefualtBuiilder which helps to create a generic web host builder sets up the default configuration and loads the appsettings.json configuration.

All the logs will be logged based on the Log level severity specified in the apsetting.json file for the logger.

Example :

 "Logging": {
    "LogLevel": {
      "Default": "Warning",
    }
  }

For the above logging configuration, only “Warning” above logs will be logged to a file.

Similarly for the below configuration Information and the above log level will be logged.

 "Logging": {
    "LogLevel": {
      "Default": "Information",
    }
  }

Serilog can also be used to override default configuration easily.

What is a Rolling file?

By configuring the log file as rolling, you get the capability to create a logging file based on dates or file size or name format, and many more custom options. Your file keeps rolling as per provided criteria.

One can use the same concept for .NET Core Console/Desktop Application logging as well.

Other useful references :

• Logging in ASP.NET Core using Built-in provider
• File Logging using NLog in ASP.NET Core

Do you have any comments or ideas or any better suggestions to share?

Please sound off your comments below.

Happy Coding !!

Summary

File/Rolling file logging provider is not yet available through the .NET Core framework and certainly, we need to depend on custom or any existing external solutions.

It’s very easy to configure file logging in .NET Core WebAPI using Serilog. Serilog helps us enable logging in a few simple steps and address the file-based logging need easily.

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post SeriLog Logging in ASP.NET Core with examples first appeared on TheCodeBuzz.

Today in this article, we will learn the top 10 differences between Kafka Vs Rabbit MQueue in Event-driven Architecture.

RabbitMQ, an open-source message broker, offers flexible messaging patterns like publish-subscribe, point-to-point, and request-response.

It focuses on ensuring reliable message delivery between components. RabbitMQ is well-suited for scenarios requiring guaranteed message delivery and queue management, such as task distribution, load leveling, and communication between microservices.

Kafka, developed by Apache, excels at handling high-throughput, real-time data streaming.

It acts as a distributed event streaming platform, where events are produced and consumed by various applications.

Kafka’s publish-subscribe model allows multiple consumers to subscribe to the same event stream, ensuring scalability and fault tolerance.

Its durability and fault-tolerant design make it suitable for scenarios demanding data integrity, such as log aggregation, real-time analytics, and monitoring.

We will cover top-level differences

Messaging Model

Kafka Messaging Model

• Kafka follows a publish-subscribe message model which is based on the push/pull model. Here subscriber doesn’t get notified automatically of the event. Here the client(Consumer) keeps polling for the data to retrieve the available message based on the consumer group.
• The key elements of Kafka’s message model are:
  • Topics: Messages in Kafka are organized into topics, which are named feeds or categories to which messages are published. Topics represent a specific stream of records, similar to a table in a database or a folder in a file system.
  • Producers: Producers are responsible for publishing messages to Kafka topics. They write data records to specific topics and determine the partition to which each record is sent. Producers can be part of a single application or distributed across multiple systems.
  • Partitions: Each topic in Kafka is divided into one or more partitions, which are ordered and immutable sequences of records. Partitions allow for parallelism and scalability by distributing the load across multiple brokers and enabling concurrent processing of messages.
  • Brokers: Kafka relies on a cluster of servers called brokers, which handle the storage and replication of message data. Each broker can be responsible for one or more partitions. Brokers work together to form a distributed and fault-tolerant message processing system.
  • Consumers: Consumers read messages from Kafka topics. They can subscribe to one or more topics and consume messages from one or more partitions. Consumers maintain their own offset, which represents the position or progress within a partition, allowing for independent and scalable message consumption.
  • Consumer Groups: Consumers can be organized into consumer groups. Each consumer within a group reads from a different subset of partitions, enabling parallel processing of messages within a topic. Consumer groups provide scalability and fault tolerance by distributing the workload across multiple consumers.
  • Retention: Kafka retains messages in topics for a configurable period or based on size limits. This retention period allows for replaying and reprocessing of messages, enabling systems to handle real-time and historical data consumption.
  • Stream Processing: Kafka’s message model supports stream processing, which involves the continuous processing of messages in real-time. Kafka Streams and other stream processing frameworks built on top of Kafka allow for stateful transformations, aggregations, and analytics on streaming data.
  • The publish-subscribe message model in Kafka provides a highly scalable and fault-tolerant architecture for handling streams of records. It allows for real-time processing, event-driven architectures, log aggregation, and building data pipelines that can handle large volumes of data efficiently.

Rabbit MQ Messaging Model

RabbitMQ follows a traditional message queueing model. The key elements of RabbitMQ’s messaging model are as follows:

• Exchanges: Exchanges receive messages from producers and route them to the appropriate queues based on predefined rules. Exchanges use different routing algorithms (e.g., direct, topic, fanout, headers) to determine how messages are distributed.
• Queues: Queues store messages until they are consumed by consumers. Messages are typically sent to a specific queue based on routing rules defined by exchanges. Queues can be created dynamically or pre-declared, and they retain messages until they are explicitly acknowledged or expired.
• Producers: Producers are responsible for creating and sending messages to RabbitMQ exchanges. They publish messages to specific exchanges, often specifying a routing key that helps determine the routing rules for message distribution.
• Consumers: Consumers retrieve and process messages from RabbitMQ queues. They subscribe to specific queues and receive messages as they become available. Consumers acknowledge the successful processing of messages to remove them from the queues.
• Binding: Bindings connect exchanges to queues based on routing rules. They define the relationship between exchanges and queues, determining how messages flow from exchanges to queues for eventual consumption by consumers.

Data Persistence details

Kafka Data Persistence details

• Kafka’s data persistence capabilities make it well-suited for use cases that involve storing and processing large volumes of data streams, event sourcing, log aggregation, and building real-time data pipelines.

• The combination of disk-based storage, replication, and configurable retention policies provides durability, fault tolerance, and scalability for reliable message handling.

Rabbit MQ Data Persistence details

• These features in RabbitMQ ensure data persistence and durability, making it suitable for various messaging scenarios that require reliable message storage, fault tolerance, and high availability.

• By leveraging disk storage, journaling, replication, and clustering, RabbitMQ provides robust persistence capabilities to handle messaging needs in distributed systems.

Message Delivery Guarantees

Kafka Message Delivery Guarantees

Kafka provides configurable message delivery guarantees to ensure reliable and fault-tolerant processing of messages.

It’s important to note that achieving exactly-once delivery requires coordination and careful implementation by both producers and consumers. Producers need to manage transactional writes, and consumers must handle idempotent processing to handle duplicate messages.

Kafka’s delivery guarantees, coupled with features like message replication, fault tolerance, and data persistence, make it suitable for building reliable data pipelines, event-driven architectures, and stream processing systems. The configurable delivery semantics allow developers to choose the appropriate level of reliability based on their specific application requirements.

Rabbit MQ Message delivery guarantee

• RabbitMQ provides flexible message delivery guarantees to ensure reliable and consistent messaging between producers and consumers.

• The message delivery guarantees in RabbitMQ can be summarized as follows.RabbitMQ’s delivery guarantees, combined with features like durable message storage, message acknowledgments, and publisher confirms, provide a solid foundation for building reliable and resilient messaging systems.

• The application Team can choose the appropriate level of delivery guarantees based on their application requirements, considering factors such as message importance, performance, and complexity of achieving exactly-once semantics.

Message Order

Kafka Message Order

Kafka ensures message order within a partition, providing a strong guarantee of message ordering at the partition level. The ordering of messages in Kafka can be summarized as follows:

It’s important to note that while Kafka guarantees message order within a partition, it does not provide global ordering across multiple partitions.

When processing messages from multiple partitions, the order of messages is not guaranteed unless additional ordering mechanisms are implemented at the application level.

By leveraging Kafka’s partitioning and ordering guarantees, applications can process and analyze data streams while maintaining the sequence and integrity of messages within each partition.

This capability is particularly valuable in scenarios where maintaining message order is crucial, such as event sourcing, stream processing, and building reliable data pipelines.

Rabbit MQ messge order

RabbitMQ maintains the order of messages. Messages are delivered to consumers in the order they were published to the queue, ensuring sequential processing within that specific queue.

By default, RabbitMQ delivers messages to consumers as soon as they become available in the queue.

To achieve global message ordering across multiple queues or consumers in RabbitMQ, you would need to implement additional mechanisms at the application level.

One approach is to use a single queue and have a single consumer process messages in a serial manner. This ensures strict ordering but sacrifices parallel processing capabilities.

Alternatively, you can introduce message sequencing or use message properties to include a sequence number that allows consumers to order messages appropriately based on their processing logic. This requires coordination and synchronization between producers and consumers to ensure correct sequencing.

Scalability and Performance

Kafka Scalability and Performance

Kafka is designed to provide high scalability and handle large-scale data streaming and processing. Its architecture and features contribute to its scalability.

Kafka operates in a distributed manner, allowing it to scale horizontally by adding more servers or brokers to the Kafka cluster. Each broker handles a subset of the data and partitions, enabling parallel processing and increased throughput.

Kafka allows for dynamic scaling of the cluster by adding or removing brokers without interrupting the data flow. This flexibility enables capacity adjustment based on traffic patterns and evolving system requirements.

Kafka’s design emphasizes high throughput and low latency. It can handle millions of messages per second and provides near-real-time processing capabilities, making it suitable for demanding workloads.

Rabbit MQ Scalability and Performance

RabbitMQ offers scalability and performance features that allow it to handle increasing message loads and ensure efficient message processing

RabbitMQ supports clustering, where multiple RabbitMQ nodes can form a cluster. Clustering enables horizontal scalability by distributing message processing across multiple nodes. Each node in the cluster can handle a portion of the message traffic, allowing for increased throughput and fault tolerance.

RabbitMQ supports connection pooling, allowing multiple clients to share connections to the RabbitMQ broker. Connection pooling minimizes overhead and improves performance by reusing established connections rather than creating new connections for each client.

Kafka’s scalability enables it to handle demanding use cases, including real-time data processing, event streaming, log aggregation, and building distributed systems. By leveraging its distributed architecture, partitioning, replication, and dynamic scaling capabilities, Kafka can accommodate growing data volumes and support high-performance data streaming applications.

Protocol Support

Kafka Protocol Support

Kafka supports its own proprietary protocol and provides client libraries for different programming languages, making it accessible and interoperable with various systems.

Kafka uses its own custom binary protocol for communication between clients and the Kafka brokers.

The protocol is designed to be efficient, lightweight, and optimized for high-performance data streaming.

Kafka’s wire-level protocol is TCP-based, providing reliable and ordered message delivery over the network.

Rabbit MQ Protocol

• Advanced Message Queuing Protocol (AMQP):
  • RabbitMQ is based on the AMQP protocol, an open standard for messaging systems.
  • RabbitMQ supports different versions of the AMQP protocol, including AMQP 0-9-1, AMQP 0-10, and AMQP 1.0.
• Simple/Streaming Text-Oriented Messaging Protocol (STOMP):
  • RabbitMQ provides support for the STOMP protocol, which is a text-based protocol for messaging interoperability.

• Message Queue Telemetry Transport (MQTT):
  • RabbitMQ offers MQTT protocol support, which is a lightweight and efficient publish-subscribe messaging protocol.

• HTTP/REST APIs:
  • RabbitMQ provides HTTP-based APIs for administrative operations, management, and monitoring of the RabbitMQ broker.
  • These APIs enable programmatic access to control and monitor RabbitMQ using standard HTTP/REST methods.

• WebSockets:
  • RabbitMQ supports WebSockets, which allow full-duplex communication over a single TCP connection, providing real-time and interactive messaging capabilities.
  • WebSockets are commonly used in web and mobile applications to enable real-time updates and push notifications.

These top 10 differences provide a high-level overview of Kafka and RabbitMQ, covering aspects such as messaging model, data persistence, delivery guarantees, scalability, protocol support, use cases, ecosystem, fault tolerance, and learning curve.

In an event-driven architecture, Kafka and RabbitMQ play vital roles as intermediaries that facilitate communication between disparate services.

Kafka’s strengths lie in real-time event streaming, making it a backbone for applications with high data throughput. RabbitMQ shines in guaranteeing reliable message delivery, making it a solid choice for scenarios where message integrity is paramount.

The selection between Kafka and RabbitMQ depends on the specific requirements of the application, with Kafka favored for high-volume, real-time data streaming and RabbitMQ for reliable message-based communication.

Consider these distinctions when choosing the messaging system that best aligns with your project requirements.

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post Top 10 Differences – Kafka Vs Rabbit MQueue in Event-driven Architecture first appeared on TheCodeBuzz.

Today, this article will help you to go over the Top 10 Best Practices for CORS -Cross-Origin Resource Sharing.

By design, Web applications execute a cross-origin HTTP request when it requests a resource that has a different origin or domain. This is due to security reasons and as per design specifications.

Enable CORS on the Server

Configure the server to include the necessary CORS headers in the HTTP response, allowing specific origins to access the resources.

Example – .NET C#

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
...

....
    app.UseCors(builder =>
        builder.AllowAnyOrigin()
               .AllowAnyMethod()
               .AllowAnyHeader());
    
....
...
}

Example – Node.js

const express = require('express');
const app = express();
const cors = require('cors');
...
...

app.use(cors());

....
....

});

Example – Java

import org.springframework.web.bind.annotation.CrossOrigin;

// Enable CORS for a specific controller
@CrossOrigin("*")
@RestController
public class WeatherController {
 // ...
}

Above both examples we are allowing any origin, any HTTP method, and any header to access your resources.

For production use, consider Restrict Origins the origin to specific origins, methods, and headers to enhance security.

Restrict Origins in CORS

Only allow trusted origins to access your resources by specifying the allowed origins using the “Access-Control-Allow-Origin” header.

Please specify the origins that are allowed to access your server resources.

This will limit cross-origin requests to only those domains that you explicitly trust.

Depending on the server-side technology you are using, the implementation may vary, but the concept remains the same.

Example – .NET C#

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
...

....
    app.UseCors(builder =>
        builder.WithOrigins("https://www.thecodebuzz.com",)
               .AllowAnyMethod()
               .AllowAnyHeader());
    
....
...
}

Example – Node.js

const express = require('express');
const app = express();
const cors = require('cors');
...
...

const allowedOrigins = ["http://TheCodebuzz.com", "http://TheCodebuzz.test.com"];

// Enable CORS for specific origins
app.use(cors({
    origin: function (origin, callback) {
        if (!origin || allowedOrigins.includes(origin)) {
            callback(null, true);
        } else {
            callback(new Error('Not allowed by CORS'));
        }
    }
}));

....
....

});

Example – Java

import org.springframework.web.bind.annotation.CrossOrigin;

// Enable CORS for a specific controller
@RestController
public class WeatherController {
// Restrict origins for this specific controller
@CrossOrigin(origins = {"http://TheCodebuzz.com", "http://Test.TheCodebuzz.com"})
 // ...
}

Validate User Input or Input request

Sanitizing input requests in an application is crucial to prevent security vulnerabilities such as SQL injection, cross-site scripting (XSS), and other malicious attacks.

Proper input validation and sanitization help ensure the integrity and security of your application. Here’s how you can sanitize input requests in your application.

Validate all incoming data against expected formats and constraints. Reject or sanitize any input that doesn’t conform to these requirements.

Handle CORS Errors

Cross-Origin Resource Sharing (CORS) errors occur when a web application makes a request to a different domain than the one from which the application was served.

Browsers enforce the same-origin policy to prevent unauthorized access, but CORS allows controlled access to resources from other origins.

CORS handling can vary based on the programming language, framework, and server you are using.

Always refer to the documentation of your specific technology stack for accurate and detailed instructions on handling CORS.

Handle CORS errors on the server side. If a request violates CORS policies, respond with an appropriate error status (e.g., 403 Forbidden) and an error message.

Optimize CORS by Caching Pre-flight Requests

Preflight requests in CORS (Cross-Origin Resource Sharing) are OPTIONS requests sent by browsers before certain cross-origin requests.

These checks determine if the actual request is safe to send. While preflight requests cannot be cached, their responses can be cached.

This can optimize subsequent CORS requests by allowing the browser to reuse the cached response without re-triggering preflight checks.

To cache preflight responses, ensure the appropriate caching headers (e.g., Cache-Control, Expires) are set in the server’s response to the OPTIONS request.

HTTP Safe Methods

Preferring safe HTTP methods for Cross-Origin Resource Sharing (CORS) is a best practice that enhances security and simplifies cross-origin communication between web applications and APIs.

Safe methods include,

• GET
• HEAD
• OPTIONS

The above safe HTTP methods are considered read-only and do not modify the server state. These Safe methods are idempotent, meaning that making multiple identical requests will have the same effect as making a single.

Security Audits of CORS policy

Periodically review and update CORS settings based on evolving security requirements to maintain a secure web application.

By following these best practices, you can ensure secure and controlled communication between different origins in your web applications, preventing unauthorized access and potential security risks associated with Cross-Origin Resource Sharing.

Summary

CORS, or Cross-Origin Resource Sharing, is a security feature implemented in web browsers to control how web pages can interact with resources from different domains

By Adding CORS, you can ensure secure and steady communication between different origins in your web applications while preventing potential security risks associated with Cross-Origin Resource Sharing.

That’s all! Happy coding!

Does this help you fix your issue?

Do you have any better solutions or suggestions? Please sound off your comments below.

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post Top 10 Best Practices for CORS first appeared on TheCodeBuzz.

NSwag and Swashbuckle are both popular libraries used for integrating Swagger/OpenAPI specifications with ASP.NET Core web applications.

Both libraries serve similar purposes, but they have some differences in terms of features and focus.

An open standard for describing and documenting APIs (Application Programming Interfaces), formerly known as Swagger, is called OpenAPI.

• It offers a machine-readable structure that makes it simple for developers to comprehend and use APIs.
• OpenAPI enables API providers to uniformly define their API’s endpoints, request, and response parameters, authentication strategies, and other key components.

Today in this article we will compare and contrast NSwag and Swashbuckle to help you make an informed decision on which one to use for your ASP.NET Core project.

What is NSwag

NSwag is a standalone library that allows you to generate Swagger specifications and API client code from existing ASP.NET Core controllers or TypeScript code.

It provides a robust set of features for both API documentation generation and API client generation. Here are some key aspects of NSwag.

NSwag, developers can save time and effort by automatically generating client code and server stubs from existing APIs or OpenAPI specifications.

This promotes consistency, reduces manual work, and simplifies the process of working with APIs in the .NET ecosystem.

Sample Nswag generated API documentation JSON,

 {
  "x-generator": "NSwag v13.4.2.0 (NJsonSchema v10.1.11.0 (Newtonsoft.Json v9.0.0.0))",
  "swagger": "2.0",
  "info": {
    "title": "MyTestService",
    "description": "My First Service",
    "termsOfService": "None",
    "contact": {
      "name": "TheCodeBuzz",
      "url": "thecodebuzz.com",
      "email": "infoatthecodebuzz.com"
    },
    "license": {
      "name": "Trademak ",
      "url": "https://www.thecodebuzz.com"
    },
    "version": "1"
  },
  "host": "localhost:44387",
  "schemes": [
    "https"
  ],
  "produces": [
    "text/plain",
    "application/json",
    "text/json"
  ],
  "paths": {
    "/api/v1/SnowForecast": {
      "get": {
        "tags": [
          "SnowForecast"
        ],
        "operationId": "SnowForecast_Get",
        "responses": {
          "200": {
            "x-nullable": false,
            "description": "",
            "schema": {
              "type": "array",
              "items": {
                "$ref": "#/definitions/WeatherForecast"
              }
            }
          }
        }
      },
      "post": {
        "tags": [
          "SnowForecast"
        ],
        "operationId": "SnowForecast_Post",
        "responses": {
          "200": {
            "x-nullable": false,
            "description": "",
            "schema": {
              "type": "array",
              "items": {
                "$ref": "#/definitions/WeatherForecast"
              }
            }
          }
        }
      }
    }
  },
  "definitions": {
    "WeatherForecast": {
      "type": "object",
      "required": [
        "date",
        "temperatureC",
        "temperatureF"
      ],
      "properties": {
        "date": {
          "type": "string",
          "format": "date-time"
        },
        "temperatureC": {
          "type": "integer",
          "format": "int32"
        },
        "temperatureF": {
          "type": "integer",
          "format": "int32"
        },
        "summary": {
          "type": "string"
        }
      }
    }
  }
}

Getting Started – NSwag Vs Swashbuckle

Please visit this article to get started,

• NSwag Swagger API documentation in ASP.NET Core

Main Feature of NSwag

Automate API Client-side Code Generation

Have you heard of legacy WSDL (WebService Schema definition file)? This file was very useful in creating client-side code-based SOAP-WCF-based services in the legacy world.

In Similar lines using NSwag, you can generate client code in multiple programming languages.

This is particularly useful for client-first development, where you want to quickly create client applications that consume your API

Available code generators:

• TypeScriptClientGenerator: Generate TypeScript clients
• CSharpClientGenerator: Generate CSharp clients
• CSharpControllerGenerator: Generate CSharp Web API controllers (contract first/schema first development)

Server Stub Generation

NSwag can generate server stubs that serve as a starting point for implementing an API’s server-side logic. These stubs can be used to scaffold the API structure and operations, and developers can then customize the generated code to implement the actual business logic.

Reverse Engineering Swagger Specification

NSwag can reverse engineer Swagger specifications from existing TypeScript or C# code.

This means you can start with your client-side code and automatically generate the API documentation from it.

This approach can be beneficial in scenarios where you want to ensure that the API specifications match the client-side implementation.

Flexibility and Customization

NSwag provides a wide range of configuration options that allow fine-tuning of the generated Swagger specifications and client code.

You can customize various aspects, such as naming conventions, property handling, and serialization settings. This level of flexibility is ideal for projects that require specific code-generation settings

CLI and Visual Studio Integration

NSwag offers command-line tools for automating the code generation process. It can also be integrated with Visual Studio as an extension, allowing developers to generate client code or server stubs directly from within the IDE.

Versatile and supports more languages

Below languages supported including,

• TypeScript,
• C#,
• Java,
• and more.

NSwag offers advanced features like the ability to generate Angular or TypeScript client code with ng-swagger-gen.

Additionally, it supports integration with ASP.NET Core MVC, Web API, and other frameworks. These features make NSwag a powerful and versatile tool for API client generation.

Code Generation Templates

NSwag provides code generation templates that can be customized to fit your specific project requirements. You have full control over the generated client code, allowing you to tailor it to match your coding standards and practices.

What is Swashbuckle

Swashbuckle is a rich library that integrates Swagger/OpenAPI support directly into ASP.NET Core applications. It provides middleware and configuration options for generating Swagger documentation and UI.

By using Swashbuckle, developers can significantly reduce the manual effort required to create and maintain API documentation. The generated Swagger/OpenAPI documentation provides a clear and comprehensive view of the API, making it easier for other developers to understand, interact with, and consume the API.

Getting Started

Please visit this article to get started,

• Add Swagger API Documentation in ASP.NET Core

Sample Swagger jSOn

{
  "openapi": "3.0.1",
  "info": {
    "title": "MyTestService",
    "version": "v1"
  },
  "servers": [
    {
      "url": "https://localhost:5001"
    }
  ],
  "paths": {
    "/WeatherForecast": {
      "post": {
        "tags": [
          "WeatherForecast"
        ],
        "parameters": [
          {
            "name": "city",
            "in": "query",
            "schema": {
              "type": "string"
            }
          },
          {
            "name": "x-customHeader",
            "in": "header",
            "required": true,
            "schema": {
              "type": "String",
              "default": "test-123456"
            }
          }
        ],
        "responses": {
          "200": {
            "description": "Success"
          }
        }
      },
      "get": {
        "tags": [
          "WeatherForecast"
        ],
        "summary": "Get weather forcast for a given city name",
        "parameters": [
          {
            "name": "city",
            "in": "query",
            "description": "city name for getting weather forcasting",
            "schema": {
              "type": "string"
            }
          },
          {
            "name": "x-customHeader",
            "in": "header",
            "required": true,
            "schema": {
              "type": "String",
              "default": "test-123456"
            }
          }
        ],
        "responses": {
          "200": {
            "description": "Success",
            "content": {
              "text/plain": {
                "schema": {
                  "type": "array",
                  "items": {
                    "$ref": "#/components/schemas/WeatherForecast"
                  }
                }
              },
              "application/json": {
                "schema": {
                  "type": "array",
                  "items": {
                    "$ref": "#/components/schemas/WeatherForecast"
                  }
                }
              },
              "text/json": {
                "schema": {
                  "type": "array",
                  "items": {
                    "$ref": "#/components/schemas/WeatherForecast"
                  }
                }
              }
            }
          }
        }
      }
    }
  },
  "components": {
    "schemas": {
      "WeatherForecast": {
        "type": "object",
        "properties": {
          "date": {
            "type": "string",
            "format": "date-time"
          },
          "temperatureC": {
            "type": "integer",
            "format": "int32"
          },
          "temperatureF": {
            "type": "integer",
            "format": "int32",
            "readOnly": true
          },
          "summary": {
            "type": "string",
            "nullable": true
          }
        },
        "additionalProperties": false
      }
    }
  }
}

Here are some key aspects of Swashbuckle

API Documentation Generation

The primary focus of Swashbuckle is on generating Swagger documentation for your API. It extracts information from your ASP.NET Core controllers, actions, and model classes to create detailed API documentation.

Simplified Setup: Swashbuckle is known for its ease of setup and use. It requires minimal configuration to get started with generating API documentation. If your main goal is to provide clear and comprehensive API documentation, Swashbuckle can be a straightforward choice.

Interactive Swagger UI

Swashbuckle includes Swagger UI, a user-friendly interface and visually appealing way that allows developers to interact with and explore the API documentation visually. Swagger UI provides a live demonstration of the API endpoints, making it easier for developers to understand how to consume the API.

Code Annotations for Documentation

Swashbuckle provides attributes that can be used to enrich the generated API documentation with additional information, such as descriptions, examples, or parameter constraints.

Customization Options

Swashbuckle offers various customization options to tailor the API documentation to specific needs. Developers can control the visibility of certain endpoints, customize UI appearance, and include additional metadata in the Swagger specification.

Integration with ASP.NET Core

Swashbuckle seamlessly integrates with ASP.NET Core middleware, making it easy to generate Swagger documentation as part of your application’s startup process. Swashbuckle is a mature library that has been widely adopted in the ASP.NET Core community. It has been continuously updated and maintained, making it a reliable choice for many projects.

Choosing Between NSwag and Swashbuckle

To decide which library is best for your ASP.NET Core project, consider the following use cases,

• Use case 1 – API Client or Server side Code Generation: If you need to generate API client code for various programming languages, NSwag is the best option. Its API client generation capabilities can significantly simplify the process of creating client applications that consume your API.

NSwag can be used to automatically generate strongly typed C# or TypeScript client code for your API.

• Client-first development: If your project follows a client-first development approach and you want to reverse engineer Swagger specifications from existing TypeScript or C# code, NSwag provides this functionality.

• Code Generation from Existing APIs: If you have an existing API implemented in a different technology or with manual code, you can use NSwag to generate C# client code or TypeScript Fetch clients for that API. This allows you to create. NET-based clients for external APIs quickly and seamlessly, enabling integration with those APIs in your .NET applications.

• Advanced Customization: If you require advanced customization options and fine-tuning of the generated Swagger specifications and client code, NSwag is the more flexible choice.

• API Documentation: If your main focus is on generating clear and comprehensive API documentation with minimal configuration, Swashbuckle’s simplicity may be preferable.

• Interactive Swagger UI: If you want to provide a visually appealing and interactive way for developers to explore your API documentation, Swashbuckle’s inclusion of Swagger UI is a valuable feature.

• Community and Support: Both NSwag and Swashbuckle have active communities and are well-supported. Consider checking their documentation, GitHub repositories, and forums to gauge the level of community engagement and support.

Summary

Both NSwag and Swashbuckle are outstanding libraries with distinct strengths.

If your project emphasizes API client generation, advanced customization, or reverse engineering from existing code, NSwag will be a the better choice.

On the other hand, if you primarily need basic API documentation with the added benefit of Swagger UI, Swashbuckle will be the better choice..

Evaluate your project requirements, the features offered by each library, and your team’s preferences to make the best decision for your ASP.NET Core application.

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post NSwag Vs Swashbuckle – What Is The Difference first appeared on TheCodeBuzz.