DEV Community: Ahsan Khan

Building Your First Web API with ASP.NET Core Part 4: Putting It All Together & Beyond

Ahsan Khan — Tue, 10 Mar 2026 00:50:52 +0000

This is the final part of a 4-part series. In Part 3, we completed the write operations POST, PUT, and DELETE. Now we take a step back, look at the big picture, and talk about where to go from here.

What We Built

Over the course of this series, we went from zero to a fully functional RESTful API. Let's take stock of everything that's now in place.

Project Structure

ContosoPizza/
├── Controllers/
│   └── PizzaController.cs     ← handles all HTTP requests
├── Models/
│   └── Pizza.cs               ← our data shape
├── Services/
│   └── PizzaService.cs        ← in-memory data layer
├── Program.cs                 ← app startup & pipeline
├── ContosoPizza.http          ← request testing file
└── ContosoPizza.csproj        ← project config

The Full API Surface

Method	Route	What It Does	Response
`GET`	`/pizza`	Returns all pizzas	`200 OK`
`GET`	`/pizza/{id}`	Returns one pizza by ID	`200` / `404`
`POST`	`/pizza`	Adds a new pizza	`201 Created`
`PUT`	`/pizza/{id}`	Replaces an existing pizza	`204` / `400` / `404`
`DELETE`	`/pizza/{id}`	Removes a pizza	`204` / `404`

Five endpoints. Full CRUD coverage. Clean status codes on every path including the unhappy ones.

How the Pieces Fit Together

It's worth zooming out and seeing how data flows through the app from a single request.

Take a POST /pizza request as an example:

The request arrives at the ASP.NET Core HTTP pipeline
The router matches /pizza to PizzaController, and the POST verb to the Create method
[ApiController] deserializes the JSON body into a Pizza object automatically
Create passes that object to PizzaService.Add()
The service assigns an ID and appends it to the in-memory list
The controller returns CreatedAtAction(...), which ASP.NET Core converts into a 201 Created response with a Location header

Every request follows this same arc: route → controller action → service → response. The controller stays thin, the service handles the logic, and the model defines the shape. That separation is what makes the code easy to extend later.

The Limitations of In-Memory Storage

Our PizzaService uses a static List<Pizza> which was perfect for learning, but has real constraints:

Data resets on every restart. Stop the server and all your pizzas are gone, back to the two defaults.
No concurrency safety. If two requests hit Add() at exactly the same time, you could get race conditions.
No persistence. Nothing is written to disk, a file, or a database.

In a real application, you'd swap the in-memory list for a proper database. The good news is that ASP.NET Core is designed for exactly this transition.

Moving to a Real Database

When you're ready to add persistence, Entity Framework Core (EF Core) is the natural next step. It's Microsoft's official ORM for .NET and integrates tightly with ASP.NET Core.

The migration path is straightforward:

1. Install EF Core:

dotnet add package Microsoft.EntityFrameworkCore.SqlServer
# or for SQLite (great for local dev):
dotnet add package Microsoft.EntityFrameworkCore.Sqlite

2. Create a DbContext:

using Microsoft.EntityFrameworkCore;
using ContosoPizza.Models;

public class PizzaContext : DbContext
{
    public PizzaContext(DbContextOptions<PizzaContext> options)
        : base(options) { }

    public DbSet<Pizza> Pizzas => Set<Pizza>();
}

3. Register it in Program.cs:

builder.Services.AddDbContext<PizzaContext>(options =>
    options.UseSqlite("Data Source=contosopizza.db"));

4. Inject it into your controller instead of calling the static service:

public class PizzaController : ControllerBase
{
    private readonly PizzaContext _context;

    public PizzaController(PizzaContext context)
    {
        _context = context;
    }

    [HttpGet]
    public ActionResult<List<Pizza>> GetAll() =>
        _context.Pizzas.ToList();
}

Your routes, attributes, and HTTP behavior stay exactly the same only the data layer changes. That's the benefit of keeping the controller and the service layer separate from the start.

What Else Should You Add?

A working CRUD API is a solid foundation. Here are the most common things you'd layer on next in a real project:

Input Validation

Right now, someone could POST a pizza with no name at all and it would go straight into the list. Data annotations let you enforce rules at the model level:

using System.ComponentModel.DataAnnotations;

public class Pizza
{
    public int Id { get; set; }

    [Required]
    [StringLength(100, MinimumLength = 1)]
    public string? Name { get; set; }

    public bool IsGlutenFree { get; set; }
}

Because [ApiController] is on your controller, invalid requests are automatically rejected with a 400 Bad Request no extra code needed.

Swagger / OpenAPI

ASP.NET Core projects come with Swashbuckle pre-installed. It generates an interactive API documentation page automatically from your controller code. Just navigate to /swagger while your app is running and you'll see every endpoint, its expected inputs, and possible responses all explorable in the browser.

Authentication & Authorization

When you're ready to lock down your endpoints, ASP.NET Core has built-in support for JWT Bearer tokens. Add the NuGet package, register the middleware, and protect specific endpoints with [Authorize]:

[Authorize]
[HttpDelete("{id}")]
public IActionResult Delete(int id) { ... }

Async All the Way

Our current service methods are synchronous. In production, especially with a real database, you'd want everything to be async/await to avoid blocking threads under load:

[HttpGet]
public async Task<ActionResult<List<Pizza>>> GetAll() =>
    await _context.Pizzas.ToListAsync();

Series Recap

Here's everything we covered across all four parts:

Part 1 What REST is, why ASP.NET Core, scaffolding the project, running it for the first time, and testing with .http files and HTTP REPL.

Part 2 How controllers, ControllerBase, [ApiController], and [Route] work; building the Pizza model and PizzaService; implementing GET endpoints.

Part 3 Implementing POST, PUT, and DELETE; understanding IActionResult vs ActionResult<T>; correct status codes on every path; end-to-end testing of all five operations.

Part 4 (this one) The full picture, in-memory storage limitations, migrating to EF Core, and the natural next steps for a production-ready API.

Final Thoughts

Building a Web API with ASP.NET Core is remarkably approachable once you understand the underlying structure. Controllers handle routing and HTTP concerns. Services handle logic. Models define the data. Each layer has a clear job.

The patterns you've learned here attribute routing, ActionResult types, proper HTTP status codes, thin controllers, separated service layers are the same ones used in large-scale production APIs. You're not learning toy concepts; you're learning the real thing.

From here, the best thing you can do is keep building. Add a second resource. Connect a real database. Explore authentication. Every layer you add will reinforce what you already know.

Good luck and thanks for following along through the whole series. 🍕

Found this series helpful? Drop a reaction or share it with someone learning .NET. Questions are always welcome in the comments!

Tags: dotnet csharp webapi aspnetcore beginners

Building Your First Web API with ASP.NET Core Part 3: Implementing POST, PUT & DELETE

Ahsan Khan — Tue, 10 Mar 2026 00:48:02 +0000

This is Part 3 of a 4-part series. In Part 2, we built our Pizza model, an in-memory data service, and wired up two GET endpoints. Now it's time to handle the write side of our API.

Where We Left Off

By the end of Part 2, our PizzaController could respond to two GET requests:

GET /pizza returns all pizzas
GET /pizza/{id} returns a specific pizza or a 404

That covers the Read in CRUD. This part finishes the job with Create, Update, and Delete using POST, PUT, and DELETE respectively.

Here's the full HTTP verb-to-CRUD mapping we're working with:

HTTP Verb	CRUD Operation	ASP.NET Core Attribute
`GET`	Read	`[HttpGet]`
`POST`	Create	`[HttpPost]`
`PUT`	Update	`[HttpPut]`
`DELETE`	Delete	`[HttpDelete]`

`IActionResult` vs `ActionResult<T>` A Quick Clarification

In Part 2, our GET methods returned ActionResult<T> a typed wrapper that tells ASP.NET Core exactly what shape the response body will have.

For write operations, we'll use IActionResult instead. Why? Because write endpoints often return no body at all just a status code. When you update a pizza successfully, you don't need to send the pizza back; a 204 No Content is enough. Since the return type isn't known until runtime, IActionResult gives us the flexibility to return different result types from the same method.

POST Adding a New Pizza

Replace the // POST action comment in PizzaController.cs with:

[HttpPost]
public IActionResult Create(Pizza pizza)
{
    PizzaService.Add(pizza);
    return CreatedAtAction(nameof(Get), new { id = pizza.Id }, pizza);
}

Let's unpack what's happening here.

The [HttpPost] attribute maps this method to POST /pizza. When the client sends a request with a JSON body, ASP.NET Core automatically deserializes it into a Pizza object no manual parsing needed. This works because the controller has [ApiController] on it, which tells the framework to look for the object in the request body by default.

The return value, CreatedAtAction, does two things at once:

Sends back a 201 Created status code
Adds a Location header to the response pointing to the newly created resource (e.g., /pizza/3)

That nameof(Get) refers to our single-item GET method from Part 2. It's used to build the URL in the Location header without hardcoding any strings.

Result	HTTP Status	When
`CreatedAtAction(...)`	`201 Created`	Pizza was added successfully
Implicit `BadRequest`	`400 Bad Request`	Request body failed model validation

PUT Updating an Existing Pizza

Replace the // PUT action comment with:

[HttpPut("{id}")]
public IActionResult Update(int id, Pizza pizza)
{
    if (id != pizza.Id)
        return BadRequest();

    var existingPizza = PizzaService.Get(id);
    if (existingPizza is null)
        return NotFound();

    PizzaService.Update(pizza);
    return NoContent();
}

A few deliberate design decisions here worth understanding.

The route is PUT /pizza/{id}, and the method takes both an id from the URL and a Pizza object from the request body. The first thing we do is check that these two IDs agree if someone sends PUT /pizza/1 with a body that has "id": 5, that's a conflicting request and we return 400 Bad Request immediately.

Next, we check whether the pizza actually exists before trying to update it. If it doesn't, 404 Not Found is the correct response not a silent no-op.

On success, we return 204 No Content. There's no need to send the updated pizza back in the response body; the client already has it since they just sent it to us.

Result	HTTP Status	When
`NoContent()`	`204 No Content`	Update was applied successfully
`BadRequest()`	`400 Bad Request`	URL id and body id don't match
`NotFound()`	`404 Not Found`	No pizza with that ID exists

DELETE Removing a Pizza

Replace the // DELETE action comment with:

[HttpDelete("{id}")]
public IActionResult Delete(int id)
{
    var pizza = PizzaService.Get(id);

    if (pizza is null)
        return NotFound();

    PizzaService.Delete(id);
    return NoContent();
}

This is the most straightforward of the three. The route is DELETE /pizza/{id} no request body needed, just the ID in the URL.

We verify the pizza exists first. If not, 404. If it does, we delete it and return 204 No Content to confirm the operation succeeded without sending anything back.

Result	HTTP Status	When
`NoContent()`	`204 No Content`	Pizza was deleted successfully
`NotFound()`	`404 Not Found`	No pizza with that ID exists

The Complete PizzaController

Here's the full controller at this point all five actions in one place:

using ContosoPizza.Models;
using ContosoPizza.Services;
using Microsoft.AspNetCore.Mvc;

namespace ContosoPizza.Controllers;

[ApiController]
[Route("[controller]")]
public class PizzaController : ControllerBase
{
    public PizzaController() { }

    [HttpGet]
    public ActionResult<List<Pizza>> GetAll() =>
        PizzaService.GetAll();

    [HttpGet("{id}")]
    public ActionResult<Pizza> Get(int id)
    {
        var pizza = PizzaService.Get(id);
        if (pizza == null)
            return NotFound();
        return pizza;
    }

    [HttpPost]
    public IActionResult Create(Pizza pizza)
    {
        PizzaService.Add(pizza);
        return CreatedAtAction(nameof(Get), new { id = pizza.Id }, pizza);
    }

    [HttpPut("{id}")]
    public IActionResult Update(int id, Pizza pizza)
    {
        if (id != pizza.Id)
            return BadRequest();

        var existingPizza = PizzaService.Get(id);
        if (existingPizza is null)
            return NotFound();

        PizzaService.Update(pizza);
        return NoContent();
    }

    [HttpDelete("{id}")]
    public IActionResult Delete(int id)
    {
        var pizza = PizzaService.Get(id);
        if (pizza is null)
            return NotFound();

        PizzaService.Delete(id);
        return NoContent();
    }
}

Clean, readable, and covers all five operations in under 50 lines of code.

Build & Run

Save the file, then verify there are no errors:

dotnet build

Start the server:

dotnet run

Testing the Write Endpoints

Open ContosoPizza.http and add the following test requests:

### Add a new pizza
POST {{ContosoPizza_HostAddress}}/pizza/
Content-Type: application/json

{
  "name": "Hawaii",
  "isGlutenFree": false
}

###

### Update it (fix the name)
PUT {{ContosoPizza_HostAddress}}/pizza/3
Content-Type: application/json

{
  "id": 3,
  "name": "Hawaiian",
  "isGlutenFree": false
}

###

### Confirm the update
GET {{ContosoPizza_HostAddress}}/pizza/3
Accept: application/json

###

### Delete it
DELETE {{ContosoPizza_HostAddress}}/pizza/3

###

### Confirm it's gone
GET {{ContosoPizza_HostAddress}}/pizza/
Accept: application/json

###

Run them in order and here's what you should see:

POST → 201 Created with the new pizza in the body and a Location header
PUT → 204 No Content (no body, just confirmation)
GET /pizza/3 → 200 OK showing the updated name "Hawaiian"
DELETE → 204 No Content
GET /pizza/ → 200 OK with only the original two pizzas ID 3 is gone

💡 Note: Since we're using in-memory storage, IDs don't persist across server restarts. Every time you run dotnet run, the list resets to the two seed pizzas.

What's Coming in Part 4,?

Our API is now fully functional. In the final part, we'll wrap everything up with:

A recap of how all the pieces fit together
A look at what you'd change moving from in-memory to a real database
Next steps for taking your API further (authentication, validation, Swagger UI)

Only one part left follow along so you don't miss the wrap-up. Questions? Drop them in the comments!

Tags: dotnet csharp webapi aspnetcore beginners

Building Your First Web API with ASP.NET Core Part 2: Controllers, Models & Your First Endpoint

Ahsan Khan — Tue, 10 Mar 2026 00:42:24 +0000

This is Part 2 of a 4-part series. In Part 1, we set up the project and got our first response from the default weather endpoint. Now it's time to build something that actually belongs to us.

Where We Left Off

At the end of Part 1, you had a running ASP.NET Core project with a scaffolded WeatherForecastController. We hit it in the browser and got back JSON great. But that controller isn't ours, and it doesn't do anything useful for a pizza inventory system.

In this part, we'll:

Understand how ASP.NET Core controllers work under the hood
Create a Pizza model to represent our data
Build an in-memory data service
Wire up a PizzaController with working GET endpoints

How Controllers Actually Work

Before writing our own controller, let's decode the sample one that came with the project. Here's the full WeatherForecastController:

using Microsoft.AspNetCore.Mvc;

namespace ContosoPizza.Controllers;

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

    private readonly ILogger<WeatherForecastController> _logger;

    public WeatherForecastController(ILogger<WeatherForecastController> logger)
    {
        _logger = logger;
    }

    [HttpGet(Name = "GetWeatherForecast")]
    public IEnumerable<WeatherForecast> Get()
    {
        return Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateTime.Now.AddDays(index),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = Summaries[Random.Shared.Next(Summaries.Length)]
        })
        .ToArray();
    }
}

There's a lot happening in a small amount of code. Let's break it down.

The Base Class: `ControllerBase`

A controller is just a public class whose public methods are exposed as HTTP endpoints. By convention, controllers live in the Controllers/ directory and their class names end with Controller.

This class inherits from ControllerBase, which gives it everything needed to handle HTTP requests parsing request data, returning status codes, sending responses. You don't write any of that plumbing yourself.

⚠️ Important: You might have seen Controller used in MVC tutorials. Don't use that here. Controller extends ControllerBase with view-rendering support, which is meant for pages not APIs.

The Two Key Attributes

Two attributes sit on top of the class definition:

[ApiController]
[Route("[controller]")]

[ApiController] turns on a set of smart, opinionated behaviors that make API development easier:

It automatically infers where parameters come from (query string, body, route, etc.)
It enforces attribute routing no routes work without explicit [Route] or HTTP verb attributes
It handles model validation errors automatically, returning a 400 Bad Request without extra code

[Route("[controller]")] maps the URL pattern for this controller. The [controller] token is a placeholder it gets replaced at runtime with the controller's class name minus the Controller suffix. So WeatherForecastController handles requests to /weatherforecast, and our upcoming PizzaController will handle /pizza.

The Action Method

[HttpGet(Name = "GetWeatherForecast")]
public IEnumerable<WeatherForecast> Get()

The [HttpGet] attribute marks this method as the handler for HTTP GET requests to this controller's route. When someone hits GET /weatherforecast, this method runs and its return value gets automatically serialized to JSON.

Creating the Pizza Model

Now that we understand the structure, let's build our own. We'll start with the data model.

1. Create a Models folder:

mkdir Models

2. Inside it, create Pizza.cs and add the following:

namespace ContosoPizza.Models;

public class Pizza
{
    public int Id { get; set; }
    public string? Name { get; set; }
    public bool IsGlutenFree { get; set; }
}

Simple and intentional an ID, a name, and a gluten-free flag. This is our core data shape. The Models/ directory name follows the model-view-controller convention, keeping things organized as the project grows.

Building the In-Memory Data Service

In a production app, you'd reach for a database. For now, we'll use a static in-memory list fast to set up, easy to understand, and perfectly fine for learning the API layer.

1. Create a Services folder:

mkdir Services

2. Inside it, create PizzaService.cs:

using ContosoPizza.Models;

namespace ContosoPizza.Services;

public static class PizzaService
{
    static List<Pizza> Pizzas { get; }
    static int nextId = 3;

    static PizzaService()
    {
        Pizzas = new List<Pizza>
        {
            new Pizza { Id = 1, Name = "Classic Italian", IsGlutenFree = false },
            new Pizza { Id = 2, Name = "Veggie",          IsGlutenFree = true  }
        };
    }

    public static List<Pizza> GetAll() => Pizzas;

    public static Pizza? Get(int id) => Pizzas.FirstOrDefault(p => p.Id == id);

    public static void Add(Pizza pizza)
    {
        pizza.Id = nextId++;
        Pizzas.Add(pizza);
    }

    public static void Delete(int id)
    {
        var pizza = Get(id);
        if (pizza is null) return;
        Pizzas.Remove(pizza);
    }

    public static void Update(Pizza pizza)
    {
        var index = Pizzas.FindIndex(p => p.Id == pizza.Id);
        if (index == -1) return;
        Pizzas[index] = pizza;
    }
}

A few things worth noting here:

The list is static, meaning it's shared across all requests for the lifetime of the app
It starts with two seed pizzas so we have something to query immediately
Every time you stop and restart the server, the list resets that's expected for in-memory storage
The service exposes GetAll, Get, Add, Update, and Delete exactly the CRUD surface our API will need

Creating the PizzaController

With our model and service in place, it's time to hook everything together.

1. Inside Controllers/, create PizzaController.cs:

using ContosoPizza.Models;
using ContosoPizza.Services;
using Microsoft.AspNetCore.Mvc;

namespace ContosoPizza.Controllers;

[ApiController]
[Route("[controller]")]
public class PizzaController : ControllerBase
{
    public PizzaController() { }

    // GET all action
    // GET by Id action
    // POST action
    // PUT action
    // DELETE action
}

The comments are placeholders we'll fill them in as we go. For now, the controller is wired to handle requests to /pizza, thanks to [Route("[controller]")].

Adding the GET Endpoints

Let's implement the two read operations first.

GET all pizzas

Replace the // GET all action comment with:

[HttpGet]
public ActionResult<List<Pizza>> GetAll() =>
    PizzaService.GetAll();

This method:

Responds exclusively to GET /pizza
Returns an ActionResult<List<Pizza>> the wrapper type that lets ASP.NET Core handle serialization and status codes correctly
Pulls the full list from our service and automatically sends it as JSON

GET a single pizza by ID

Replace the // GET by Id action comment with:

[HttpGet("{id}")]
public ActionResult<Pizza> Get(int id)
{
    var pizza = PizzaService.Get(id);

    if (pizza == null)
        return NotFound();

    return pizza;
}

This method:

Handles GET /pizza/{id} a separate route from the one above
Returns a 404 Not Found if no matching pizza exists, via the built-in NotFound() helper
Returns the pizza object directly (serialized to JSON) if found

Here's how the status codes map:

Result	HTTP Status	When
Returns pizza	`200 OK`	ID matched a pizza in the list
`NotFound()`	`404 Not Found`	No pizza with that ID exists

Build & Test

Make sure everything compiles cleanly:

dotnet build

Then start the server:

dotnet run

Test with the .http file

Open ContosoPizza.http and add these requests below the existing ones:

GET {{ContosoPizza_HostAddress}}/pizza/
Accept: application/json

###

GET {{ContosoPizza_HostAddress}}/pizza/1
Accept: application/json

###

GET {{ContosoPizza_HostAddress}}/pizza/5
Accept: application/json

###

Hit Send Request on each one. You should see:

/pizza/ → 200 OK with both pizzas as a JSON array
/pizza/1 → 200 OK with just "Classic Italian"
/pizza/5 → 404 Not Found (that ID doesn't exist)

That last one is important your API handles bad input gracefully without any extra work from you.

What's Coming in Part 3?

The read side of our API is working. In Part 3, we'll implement the write operations:

POST /pizza add a new pizza
PUT /pizza/{id} update an existing one
DELETE /pizza/{id} remove it from the list

We'll also cover how IActionResult differs from ActionResult<T> and why it matters for write operations.

Questions so far? Drop them in the comments. See you in Part 3,!

Tags: dotnet csharp webapi aspnetcore beginners

Building Your First Web API with ASP.NET Core Part 1: Getting Started with REST

Ahsan Khan — Tue, 10 Mar 2026 00:38:25 +0000

This is Part 1 of a 4-part series where we build a fully functional RESTful Web API using ASP.NET Core controllers and C#. By the end of the series, you'll have a working API that handles create, read, update, and delete (CRUD) operations.

What Are We Building?

Imagine you've just joined the dev team at a pizza company. Your first task? Build the backend API that will power both the company's website and mobile app specifically, an inventory management system for pizzas.

That means your API needs to support:

Fetching the full pizza catalog
Adding new pizza types
Updating existing entries
Removing items that are discontinued

This is a perfect real-world scenario to understand REST and ASP.NET Core controllers, so let's dig in.

What is REST, Anyway?

Before writing a single line of code, it helps to understand what REST actually means in practice.

REST (Representational State Transfer) is an architectural pattern for designing networked services. It uses standard HTTP verbs the same ones your browser uses every day to perform operations on resources.

Here's the quick mapping:

HTTP Verb	What It Does
`GET`	Fetch data
`POST`	Create something new
`PUT`	Replace/update existing data
`PATCH`	Partially modify existing data
`DELETE`	Remove data

A RESTful API is defined by three things: a base URI (like https://api.example.com), these HTTP methods, and a data format usually JSON, sometimes XML.

Routing ties it all together. For example, requests to /pizza might go to a PizzaController, while /order routes to an OrderController. Each resource gets its own logical home in your code.

Why ASP.NET Core for Web APIs?

You might be wondering why ASP.NET Core specifically? A few reasons stand out:

JSON out of the box. You don't need to configure anything special to return JSON. ASP.NET Core serializes your C# classes automatically.

Security built in. HTTPS is enabled by default, and there's native support for JWT-based authentication and flexible, policy-driven authorization.

Attribute-based routing. Instead of managing routing in a central config file, you define routes directly on your controller methods using attributes. Clean and co-located.

Code reuse across .NET. The same models and business logic you write for your API can be shared with mobile, desktop, or other .NET services no duplication needed.

Prerequisites

Before following along, make sure you have:

Basic familiarity with C# (beginner level is fine)
.NET 8 SDK installed locally
Visual Studio Code
The C# Dev Kit extension for VS Code
The REST Client extension for VS Code

To confirm your .NET version, run this in your terminal:

dotnet --list-sdks

You should see something like 8.0.100 in the output. If not, grab the latest .NET 8 SDK from the link above.

Creating the Project

Open VS Code, then:

Go to File > Open Folder and create a new folder called ContosoPizza
Open the integrated terminal via View > Terminal
Run the following command:

dotnet new webapi -controllers -f net8.0

This scaffolds a new ASP.NET Core Web API project with controller support. You'll end up with a structure like this:

├── Controllers/
├── obj/
├── Properties/
├── appsettings.Development.json
├── appsettings.json
├── ContosoPizza.csproj
├── ContosoPizza.http
├── Program.cs
└── WeatherForecast.cs

Here's what matters most right now:

Controllers/ Where your API endpoint logic lives
Program.cs App startup configuration and HTTP pipeline
ContosoPizza.http A handy file for testing your API right inside VS Code
ContosoPizza.csproj Project metadata and dependencies

💡 VS Code might prompt you to add debugging assets. Click Yes it's worth it.

Running It for the First Time

Start the dev server with:

dotnet run

You'll see output similar to:

Now listening on: https://localhost:7294
Now listening on: http://localhost:5118
Application started. Press Ctrl+C to shut down.

Note your HTTPS port number you'll need it throughout this series.

Now open your browser and navigate to:

https://localhost:{PORT}/weatherforecast

You should see a JSON response with randomized weather data that's the sample endpoint ASP.NET scaffolded for you. It proves everything is wired up correctly.

Testing with the .http File

The project includes a ContosoPizza.http file that works with the REST Client extension you installed. Open it up it should already have a GET request pointed at the /weatherforecast endpoint.

Click Send Request above the GET line, and you'll see the full HTTP response in a side panel:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
...

[
  {
    "date": "2024-01-18",
    "temperatureC": -2,
    "temperatureF": 29,
    "summary": "Warm"
  },
  ...
]

This is a great workflow no need to leave VS Code to test your endpoints.

Optional: Explore with HTTP REPL

If you prefer the terminal, ASP.NET Core has a dedicated interactive tool for API exploration called HTTP REPL. Install it with:

dotnet tool install -g Microsoft.dotnet-httprepl

Then connect to your running API:

httprepl https://localhost:{PORT}

From there, you can browse your API like a file system:

ls                    # See available endpoints
cd WeatherForecast    # Navigate to an endpoint
get                   # Fire a GET request
exit                  # Quit the REPL

It's a neat way to explore and verify your API structure as you build it.

What's Coming in Part 2,?

Right now, the project just has a sample weather forecast endpoint. In Part 2, we'll:

Understand how ASP.NET Core controllers actually work
Break down the WeatherForecastController code
Create a Pizza model and an in-memory data service
Wire up our own PizzaController

By the end of Part 2, you'll be fetching pizza data through your own API endpoint.

Follow along so you don't miss the next part. If you have questions or run into setup issues, drop them in the comments!

Tags: dotnet csharp webapi aspnetcore beginners

DEV Community: Ahsan Khan

Building Your First Web API with ASP.NET Core Part 4: Putting It All Together & Beyond

What We Built

Project Structure

The Full API Surface

How the Pieces Fit Together

The Limitations of In-Memory Storage

Moving to a Real Database

What Else Should You Add?

Input Validation

Swagger / OpenAPI

Authentication & Authorization

Async All the Way

Series Recap

Final Thoughts

Building Your First Web API with ASP.NET Core Part 3: Implementing POST, PUT & DELETE

Where We Left Off

IActionResult vs ActionResult<T> A Quick Clarification

POST Adding a New Pizza

PUT Updating an Existing Pizza

DELETE Removing a Pizza

The Complete PizzaController

Build & Run

Testing the Write Endpoints

What's Coming in Part 4,?

Building Your First Web API with ASP.NET Core Part 2: Controllers, Models & Your First Endpoint

Where We Left Off

How Controllers Actually Work

The Base Class: ControllerBase

The Two Key Attributes

The Action Method

Creating the Pizza Model

Building the In-Memory Data Service

Creating the PizzaController

Adding the GET Endpoints

GET all pizzas

GET a single pizza by ID

Build & Test

Test with the .http file

What's Coming in Part 3?

Building Your First Web API with ASP.NET Core Part 1: Getting Started with REST

What Are We Building?

What is REST, Anyway?

Why ASP.NET Core for Web APIs?

Prerequisites

Creating the Project

Running It for the First Time

Testing with the .http File

Optional: Explore with HTTP REPL

What's Coming in Part 2,?

`IActionResult` vs `ActionResult<T>` A Quick Clarification

The Base Class: `ControllerBase`