AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Csharp Api Controller Standards

skill-linuxchata-ai-playbook-csharp-api-controller-standards · by linuxchata

Defines the coding standards, patterns, and conventions for ASP.NET Core REST API controllers. Rules cover routing, HTTP verbs, response types, XML documentation, dependency injection, and asynchronous execution. Apply these rules uniformly to ensure a consistent, predictable, and well-documented API surface.

No reviews yet
0 installs
44 views
0.0% view→install

Install

$ agentstack add skill-linuxchata-ai-playbook-csharp-api-controller-standards

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-linuxchata-ai-playbook-csharp-api-controller-standards)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
4mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Csharp Api Controller Standards? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

C# ASP.NET Core API Controller Standards

Description

Defines the coding standards, patterns, and conventions for ASP.NET Core REST API controllers. Rules cover routing, HTTP verbs, response types, XML documentation, dependency injection, and asynchronous execution. Apply these rules uniformly to ensure a consistent, predictable, and well-documented API surface.


1. Controller Structure & Inheritance

1.1 Base Class and Attributes

  • All API controllers must inherit from ControllerBase (not Controller, which includes view rendering logic).
  • Decorate all controllers with the [ApiController] attribute to enable automatic model validation, API behavior conventions, and attribute routing requirements.
  • Use the [Route] attribute at the class level to define the base path.
// ✅ Correct
[ApiController]
[Route("api/[controller]")]
public sealed class OrdersController : ControllerBase
{
}

// ❌ Wrong
public class OrdersController : Controller { }

2. Routing Conventions

2.1 Resource Naming

  • Use nouns, not verbs, for endpoint paths.
  • Prefer [controller] in the Route attribute to automatically use the controller name (minus the "Controller" suffix).

2.2 Route Parameters

  • Specify route parameters explicitly in the HTTP verb attributes.
  • Match route parameter names exactly with the method parameter names.
[HttpGet("{id:guid}")]
public async Task GetByIdAsync(Guid id, CancellationToken cancellationToken)

3. HTTP Methods & Attributes

3.1 Standard Verbs

Use the correct HTTP verb corresponding to the operation:

| Verb | Usage | Idempotent | |---|---|---| | [HttpGet] | Retrieve a resource or collection | Yes | | [HttpPost] | Create a new resource or execute an action | No | | [HttpPut] | Fully update an existing resource | Yes | | [HttpPatch] | Partially update an existing resource | No | | [HttpDelete] | Remove a resource | Yes |

3.2 Action Parameters Binding

Explicitly state where parameters are bound from to avoid ambiguity and improve OpenAPI generation:

  • [FromRoute]: For IDs and path segments.
  • [FromQuery]: For filtering, paging, and sorting parameters.
  • [FromBody]: For complex objects in POST/PUT/PATCH requests.
[HttpGet("{id:guid}/items")]
public async Task GetItemsAsync(
    [FromRoute] Guid id, 
    [FromQuery] int page, 
    CancellationToken cancellationToken)

4. Responses & Status Codes

4.1 Explicit Action Results

  • Return IActionResult or ActionResult.
  • Use the built-in helper methods (Ok(), Created(), NotFound(), BadRequest(), NoContent()) to generate responses.

4.2 Standard Status Codes

Always return the appropriate HTTP status code for the outcome:

  • 200 OK: Successful GET.
  • 201 Created: Successful POST that creates a resource. Might include a Location header pointing to the new resource.
  • 204 No Content: Successful operation that returns no body (e.g., DELETE, PUT, PATCH).
  • 400 Bad Request: Client error (validation failure, invalid input).
  • 401 Unauthorized: Authentication required.
  • 403 Forbidden: Authenticated, but lacks permission.
  • 404 Not Found: The requested resource ID does not exist.
  • 409 Conflict: Resource state conflict (e.g., trying to create a duplicate).
[HttpPost]
public async Task CreateAsync([FromBody] CreateOrderRequest request, CancellationToken cancellationToken)
{
    var id = await _service.CreateAsync(request, cancellationToken);
    return CreatedAtAction(nameof(GetByIdAsync), new { id = id }, request);
}

4.3 [ProducesResponseType]

Explicitly declare all possible status codes and their corresponding return types using [ProducesResponseType]. This is critical for generating accurate OpenAPI/Swagger documentation.

[HttpGet("{id:guid}")]
[ProducesResponseType(typeof(OrderDto), StatusCodes.Status200OK)]
[ProducesResponseType(StatusCodes.Status404NotFound)]
public async Task GetByIdAsync([FromRoute] Guid id, CancellationToken cancellationToken)

5. XML Documentation

5.1 Public API Contracts

Every controller action must be fully documented using XML comments.

XML comment tags:

  • ``: A brief, single-sentence description of what the endpoint does.
  • ``: (Optional) Detailed information, usage examples, or nuances.
  • ``: Description of each input parameter.
  • ``: Description of the HTTP response.
  • ``: Description of each possible HTTP status code returned.
/// 
/// Retrieves a specific order by its unique identifier.
/// 
/// The unique identifier of the order.
/// A cancellation token.
/// The HTTP response.
/// A specific order.
/// If the order is not found.
[HttpGet("{id:guid}")]
[ProducesResponseType(typeof(OrderDto), StatusCodes.Status200OK)]
[ProducesResponseType(StatusCodes.Status404NotFound)]
public async Task GetByIdAsync([FromRoute] Guid id, CancellationToken cancellationToken)
{
    // ... implementation
}

6. Dependency Injection

6.1 Constructor Injection

Always use constructor injection for services required by the controller.

If using C# 12 or later, prefer Primary Constructors to eliminate boilerplate:

// ✅ Correct (C# 12+)
[ApiController]
[Route("api/[controller]")]
public sealed class OrdersController(
    IOrderService orderService, 
    ILogger logger) : ControllerBase
{
    // Dependencies are available directly as parameters
}

If using C# 11 or earlier, store dependencies in private readonly fields and use a traditional constructor:

// ✅ Correct (C# 11 and earlier)
[ApiController]
[Route("api/[controller]")]
public sealed class OrdersController : ControllerBase
{
    private readonly IOrderService _orderService;
    private readonly ILogger _logger;

    public OrdersController(IOrderService orderService, ILogger logger)
    {
        _orderService = orderService;
        _logger = logger;
    }
}

7. Asynchronous Execution

7.1 Async All The Way

  • All controller actions must be async Task or async Task>.
  • Always append the Async suffix to the action method name. ASP.NET Core routing automatically removes the Async suffix when mapping route names (e.g., CreatedAtAction).
  • Every action must accept a CancellationToken as its final parameter and pass it down to all async service calls.
// ✅ Correct
[HttpDelete("{id:guid}")]
[ProducesResponseType(StatusCodes.Status204NoContent)]
[ProducesResponseType(StatusCodes.Status404NotFound)]
public async Task DeleteAsync([FromRoute] Guid id, CancellationToken cancellationToken)
{
    var result = await _orderService.DeleteAsync(id, cancellationToken);
    return result ? NoContent() : NotFound();
}

Quick Reference Checklist

Before submitting an API controller, verify:

  • [ ] Inherits from ControllerBase and has [ApiController] and [Route] attributes
  • [ ] Route uses plural nouns (e.g., api/users)
  • [ ] Correct HTTP verb attribute used ([HttpGet], [HttpPost], etc.)
  • [ ] Input parameters have explicit binding attributes ([FromRoute], [FromBody], etc.)
  • [ ] Action is async Task and method name ends with Async
  • [ ] CancellationToken is the last parameter and is passed down
  • [ ] XML `, , and ` tags are complete
  • [ ] [ProducesResponseType] covers all possible HTTP status codes returned
  • [ ] Returns correct standard HTTP status codes (200, 201, 204, 400, 404, etc.)

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.