Getting Started with ASP.NET Core Web API in Rider
A simple “Hello Flow” to understand Controllers, Services, and Dependency Injection
Introduction
I originally used VS Code for C# development. After trying JetBrains Rider, I found it more comfortable—especially when learning ASP.NET Core and understanding project structure.
Everything shown in this post can also be done in VS Code. The code itself is not tied to Rider. However, the initial setup steps may differ, and if you use VS Code, you may need to search for and configure some parts on your own.
This post focuses on understanding structure and flow, not on IDE-specific features.
1️⃣ Creating a New Project (Laying the Foundation)
- Open Rider and click New Solution
- Select ASP.NET Core Web API from the left menu
-
Configure the project (important):
- Solution name: HelloFlow
- Type: Web API
- Framework: net8.0 (or the latest version)
- Authentication: None
- Docker Support: Disabled (we will learn this later)
- Use Controllers: Checked Depending on the Rider version, this may appear as disabling “Minimal API”. The key point is that we want to use Controllers.
- OpenAPI Support: Checked
- Click Create
2️⃣ Cleaning Up (Removing Template Files)
After the project opens, you will see several default files. These are only sample files and are not required for this walkthrough.
- Delete
WeatherForecast.cs - Delete
Controllers/WeatherForecastController.cs
3️⃣ Preparing the Structure (Creating Space)
- Right-click the project name (
HelloFlow) - Select Add → New Folder
- Name it
Services
Your project structure should now look like this:
Solution 'HelloFlow'
└─ HelloFlow
├─ Controllers/
├─ Services/
├─ Properties/
├─ appsettings.json
└─ Program.cs
Phase 0: The “Hello Loop” (Understanding the Flow)
We will add a very small feature: a function that returns a simple greeting string.
The most important rule in this phase is:
Controllers handle requests. Services do the real work.
We will build this in three steps:
- Service – where the actual logic lives
- Controller – receives requests and forwards them
- Program.cs – connects everything together
1️⃣ Step 1: The Kitchen (Service)
The Service contains business logic only.
It does not know anything about HTTP, routing, or controllers.
Flow
- Input: none
- Output: a string
Role
- HelloService: creates the actual result
Code
namespace HelloFlow.Services;
public class HelloService
{
public string GetMessage()
{
return "Hello from Switzerland!";
}
}
This class does only one thing:
- It creates a result
- It does not care who calls it or how it is used
2️⃣ Step 2: The Counter (Controller)
The Controller interacts with the outside world through HTTP.
Flow
- A request comes in:
GET /api/hello - The controller does not create the message itself
- The work is delegated to
HelloService - The result is returned as an HTTP response
Roles
- ControllerBase: marks the class as a web controller
- Constructor: declares required dependencies
Code
using Microsoft.AspNetCore.Mvc;
using HelloFlow.Services;
namespace HelloFlow.Controllers;
[ApiController]
[Route("api/[controller]")]
public class HelloController : ControllerBase
{
private readonly HelloService _service;
public HelloController(HelloService service)
{
_service = service;
}
[HttpGet]
public IActionResult SayHello()
{
var message = _service.GetMessage();
return Ok(message);
}
}
The key idea here is simple:
- The controller does not work alone
- It explicitly declares what it needs to function
3️⃣ Step 3: Registration (Program.cs)
If we stop here, the application will fail at runtime.
The controller requests HelloService, but no one has created it yet.
That responsibility belongs to Program.cs.
Flow
- Services are registered when the application starts
- Dependencies are injected automatically when needed
Code
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();
// Register HelloService
builder.Services.AddScoped<HelloFlow.Services.HelloService>();
var app = builder.Build();
This line means:
“If someone asks for HelloService, create one and provide it.”
4️⃣ Run and Verify
- Click the Run button in Rider
- The browser opens with Swagger UI
- Find
GET /api/hello - Click Try it out → Execute
If the response is:
"Hello from Switzerland!"
Everything is working as expected.
🧠 One Sentence That Matters Most
The web only forwards requests. Real work happens in Services.
🧩 The Big Picture
[Browser]
↓
[Controller]
↓
[Service]
- The browser sends a request
- The controller receives and forwards it
- The service creates the result
✅ Three Key Takeaways
- Controllers do not contain business logic
- Services do the real work
-
Program.csconnects everything together
✍️ My Notes & Reflections
- I understood that a controller does not control the application logic. It simply receives requests from the browser and passes them along.
-
The controller only delivers the result it gets from a service.
All real control over how services are created and connected happens in
Program.cs. -
When a different type of service is needed, the controller is not involved.
The change is handled in
Program.cs, not inside the controller. - Thinking of the controller as a conveyor belt helped me. It does not decide what happens; it just moves requests and responses along the flow.
Top comments (0)