ASP.NET Core Web API Project Setup

📚 DotNet Fullstack + Angular 📂 Chapter 33: Web API Fundamentals — REST and Project Setup 📄 Lesson 33020 Beginner 🕒 March 17, 2026

Setting up an ASP.NET Core Web API project correctly from the start — with the right JSON serialisation, the right DI registrations, and the right project structure — prevents a class of configuration bugs that only surface when Angular or other clients connect. The Web API template is a good starting point, but production APIs need additional configuration: strict JSON casing, null handling, enum serialisation, and Swagger documentation.

Web API Project Setup

// dotnet new webapi -n BlogApp.Api -o src/BlogApp.Api --no-openapi
// (we configure Swagger manually for full control)

// ── Program.cs — production Web API configuration ─────────────────────────
var builder = WebApplication.CreateBuilder(args);

// ── Register controllers with JSON configuration ──────────────────────────
builder.Services
    .AddControllers(options =>
    {
        // Return 406 Not Acceptable for unsupported media types
        options.ReturnHttpNotAcceptable = true;
        // Add XML support (optional)
        options.RespectBrowserAcceptHeader = true;
    })
    .AddJsonOptions(options =>
    {
        // camelCase for all property names: "postId", "createdAt"
        options.JsonSerializerOptions.PropertyNamingPolicy =
            JsonNamingPolicy.CamelCase;

        // Omit null values from responses (smaller payloads)
        options.JsonSerializerOptions.DefaultIgnoreCondition =
            JsonIgnoreCondition.WhenWritingNull;

        // Serialize enums as strings: "Published" not 1
        options.JsonSerializerOptions.Converters.Add(
            new JsonStringEnumConverter());

        // Ignore circular references (for navigation properties)
        options.JsonSerializerOptions.ReferenceHandler =
            ReferenceHandler.IgnoreCycles;
    });

// ── CORS for Angular client ────────────────────────────────────────────────
builder.Services.AddCors(opts =>
    opts.AddPolicy("AllowAngular",
        p => p.WithOrigins("http://localhost:4200")
              .AllowAnyMethod()
              .AllowAnyHeader()));

// ── Health checks ─────────────────────────────────────────────────────────
builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>("database");

var app = builder.Build();

app.UseHttpsRedirection();
app.UseCors("AllowAngular");       // before UseAuthentication
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();
app.MapHealthChecks("/health");

app.Run();

Note: AddControllers() registers only the Web API components — no Razor view engine, no HTML helpers, no static file support. Use AddControllersWithViews() for MVC applications or when you want both API and server-rendered HTML in the same project. Use AddControllers() for pure API projects. The difference is not just semantics — AddControllersWithViews() loads the Razor compilation infrastructure (significant startup overhead and memory) that a pure API project does not need.

Tip: Configure JsonNamingPolicy.CamelCase globally in AddJsonOptions() so all JSON responses use camelCase property names that match Angular/JavaScript conventions. Without this, C# PascalCase property names (PostId, CreatedAt) appear as-is in JSON responses and Angular code must use post.PostId instead of the idiomatic post.postId. CamelCase is the standard for REST APIs consumed by JavaScript clients.

Warning: ReferenceHandler.IgnoreCycles silently drops circular references in JSON serialisation. This is usually correct (you don’t want to serialise the full navigation graph), but be aware that some data will be missing if your entity navigation properties create cycles. The alternative ReferenceHandler.Preserve uses JSON reference syntax ($id, $ref) which Angular does not understand natively. Design your DTOs to explicitly control which navigation properties are included, rather than relying on cycle handling.

Project Structure for Part 4

// ── Recommended multi-project structure for Part 4 ─────────────────────────
// BlogApp/
// ├── src/
// │   ├── BlogApp.Domain/           ← Chapter 33–34: entities, value objects
// │   ├── BlogApp.Application/      ← Chapter 35–39: services, DTOs, interfaces
// │   ├── BlogApp.Infrastructure/   ← Chapter 37–38: EF Core, repositories
// │   └── BlogApp.Api/              ← Chapter 33–46: controllers, middleware
// │       ├── Controllers/
// │       │   ├── PostsController.cs
// │       │   ├── UsersController.cs
// │       │   └── CommentsController.cs
// │       ├── DTOs/                 ← Request/response DTOs
// │       ├── Extensions/           ← IServiceCollection extensions
// │       └── Program.cs
// └── tests/
//     ├── BlogApp.Unit.Tests/
//     └── BlogApp.Integration.Tests/

// ── Project references ────────────────────────────────────────────────────
// BlogApp.Api → BlogApp.Application → BlogApp.Domain
// BlogApp.Api → BlogApp.Infrastructure → BlogApp.Application

Common Mistakes

Mistake 1 — Using AddControllersWithViews for a pure Web API (loads unused Razor engine)

❌ Wrong — loads Razor compilation infrastructure for an API that never renders HTML.

✅ Correct — use AddControllers() for Web APIs; AddControllersWithViews() only when Razor views are needed.

Mistake 2 — Not configuring camelCase JSON (Angular clients need camelCase)

❌ Wrong — API returns PascalCase: { "PostId": 1, "Title": "Hello" }; Angular code awkward.

✅ Correct — configure PropertyNamingPolicy = JsonNamingPolicy.CamelCase globally.

Web API Project Setup #

Project Structure for Part 4 #

Common Mistakes #

Mistake 1 — Using AddControllersWithViews for a pure Web API (loads unused Razor engine) #

Mistake 2 — Not configuring camelCase JSON (Angular clients need camelCase) #

🧠 Test Yourself #

📚 More in this Tutorial Series

Web API Project Setup

Project Structure for Part 4

Common Mistakes

Mistake 1 — Using AddControllersWithViews for a pure Web API (loads unused Razor engine)

Mistake 2 — Not configuring camelCase JSON (Angular clients need camelCase)

🧠 Test Yourself