dealing with Web API and MVC in the same service

[zijianhuang]

Solution 1:

Wildcard of controller exclusion.

Solution 2:

Check ApiController when enumerating controllers.

Solution 1 is likely enough, unless there are a lot real world cases demanding solution 2.

1. MyBusiness.Domain.Mvc* will be excluded

		string[] excludedControllerNames;
		/// <summary>
		/// Filters to exclude some controllers. For example, [My.Namespace.Home, My.Namespace.FileUpload] for My.Namespace.HomeController and My.Namespace.FileUploadController.
		/// Wildcard "My.Mvc*" will filter out "My.Mvc.Home" and "My.MvcSomething".
		/// </summary>
		public string[] ExcludedControllerNames
		{
			get { return excludedControllerNames; }
			set
			{
				excludedControllerNames = value;
				var candidates = excludedControllerNames.Where(d=> d.EndsWith('*')).ToArray();
				if (candidates.Length > 0)
				{
					excludedWildCard = candidates.Select(d => d.TrimEnd('*')).ToArray();
				}
			}
		}

		string[] excludedWildCard;

implemented. Until next release.

[zijianhuang]

In ASP.NET Core programming, in reality, how often developers would put Web API and MVC controllers in the same Web service?

M365 Copilot:
Short answer: it’s pretty common—but not universal—to host MVC (Razor views) and Web API controllers in the same ASP.NET Core app. Teams do it when it keeps deployment simple and the UI is tightly coupled to the same domain/services. That said, many teams split them once scale, ownership, or release cadence diverge.

Here’s how it tends to play out in practice.

---

When teams put MVC and Web API together (quite common)

Typical scenarios

• Server-rendered web app with a few SPA/JS features: Razor pages/views plus some API endpoints for AJAX or a small React/Vue component.
• Internal/business tools: One codebase is easier to maintain and deploy; shared auth and DI.
• Monolith-first approach: Start together for speed; extract later if needed.

Why it works

• Single deployment & ops: One app, one pipeline, one domain.
• Shared code & DI: Same services, filters, model binding, validation.
• Consistent auth: Same cookies/tokens, policies, middleware.

Trade-offs

• Coupling: UI and API release together—even if you only changed one.
• Blast radius: Issues in UI can affect API availability/latency and vice versa.
• Security surface: A public web app + API combined can expand the attack surface if not segmented carefully (routes, auth policies, rate limits).

---

When teams separate them (also common)

Typical triggers

• Different consumers: Mobile apps, third-party partners, or many internal services rely on the API.
• Different SLAs & release cadence: API needs stability/versioning; the web app moves faster.
• Scale & performance isolation: Independent scaling (e.g., API scaled for throughput, web scaled for caching).
• Org boundaries: Separate teams/ownership.

Benefits of separation

• Independent lifecycles: Versioning, canary releases, blue/green, rollbacks.
• Security isolation: API behind gateways (e.g., rate limiting, WAF), web app can be separate trust zone.
• Operational clarity: Monitoring and SLOs tailored per surface.

Costs

• More infra: Extra repos, pipelines, domains, and coordination.
• Duplication risk: Shared contracts and models need a package/shared library or OpenAPI-first approach.

---

Practical patterns if you keep them together

• Route hygiene

  • Keep APIs under /api/* and MVC under / or /app/*.
  • Use separate controllers: ApiController (with [ApiController] attribute) vs Controller.

• Policies & middleware

  • Apply stricter auth/authorization on API endpoints (JWT/bearer) even if the site uses cookies.
  • Consider rate limiting middleware for API routes only.

• Versioning & documentation

  • Add API versioning (api/v1, api/v2) to avoid breaking UI or other consumers.
  • Use OpenAPI/Swagger but hide it behind auth and only expose in non-prod or via gated paths.

• Performance isolation

  • Separate endpoint conventions (e.g., JSON-only for API).
  • Cache layer tuned differently: server-side output caching for MVC pages; response caching for API.

• Testing discipline

  • Contract tests for API; integration/UI tests for MVC. Keep these logically separated in test projects.

---

Practical patterns if you split them

• Contract-first: Use OpenAPI as the source of truth; generate clients for the MVC app and other consumers.
• Shared packages: Share DTOs and validators via a NuGet package to avoid drift.
• Gateway/front-door: Put the API behind an API gateway or reverse proxy with policies separate from the web app.
• CI/CD: Independent pipelines with semantic versioning for the API.

---

What I see most in the wild

• Small-to-mid apps: Start combined (MVC + Web API in one project). Works well and ships faster.
• Growing products: Move API out once mobile/partners join, or when uptime/perf requirements diverge.
• Modern greenfield: If the UI is a SPA hosted statically (e.g., Azure Static Web Apps, S3/CloudFront), the API is often separate from day 1.
• Minimal APIs: Teams sometimes add Minimal APIs alongside MVC for lightweight endpoints—still in the same app—because it’s ergonomically easy.

---

Recommendation

• If you’re early-stage or have a primarily server-rendered app with light API needs: keep them together for simplicity.
• Start with clear boundaries (routing, auth, versioning), so you can extract the API later with minimal churn.
• If you already have or expect multiple independent consumers, strict SLAs, or different scaling/security profiles: separate them now.

---

If you want, tell me a bit about your project (consumer types, deployment model, expected scale, team size), and I can recommend an architecture and show a minimal setup for routing, auth, versioning, and Swagger tailored to your case.

[zijianhuang]

using [ApiController] on your ASP.NET Core Web API controllers is a good practice** (and generally recommended) because it turns on a set of API‑friendly behaviors that make your endpoints safer, more predictable, and less boilerplate-y.

Below is what it does, why it’s helpful, and a few caveats.

---

What [ApiController] enables (and why it’s useful)

1. Automatic 400 responses for validation errors

   • If model binding/validation fails (e.g., ModelState.IsValid == false), ASP.NET Core automatically returns a 400 Bad Request with a ProblemDetails payload.
   • You don’t need to write if (!ModelState.IsValid) ... in every action anymore.
   • Benefit: Less boilerplate, consistent error responses.

2. ProblemDetails formatting by default

   • Errors conform to RFC 7807 (application/problem+json), making errors consistent and machine‑friendly.
   • Benefit: Better client experience and easier debugging and tooling integration.

3. Binding source inference

   • For action parameters, the framework infers where to bind from:
     • Complex types ⇒ from body (JSON)
     • Simple/primitive types ⇒ from route or query string
     • IFormFile and related ⇒ from form
   • You often don’t need to add [FromBody]/[FromQuery]/[FromRoute] explicitly.
   • Benefit: Cleaner action signatures; less chance of binding mistakes.

4. Attribute routing is required

   • Controllers must use attribute routing (e.g., [Route("api/[controller]")], [HttpGet], etc.).
   • Benefit: Clear, explicit routes which are typical for APIs.

5. Automatic error responses for missing/ambiguous sources

   • If a required parameter can’t be bound or the source is ambiguous, you get a 400 with details rather than a null value silently slipping through.
   • Benefit: Fail early & loudly with actionable messages.

6. Better API Explorer / Swagger experiences

   • The conventions play nicely with Swashbuckle/NSwag—fewer surprises in generated OpenAPI docs.

These behaviors are controlled via ApiBehaviorOptions (e.g., options.SuppressModelStateInvalidFilter = true to turn off auto-400) if you need to tweak them.

---

You can also customize behavior in Program.cs:

builder.Services.AddControllers()
    .ConfigureApiBehaviorOptions(options =>
    {
        // Example: opt out of auto-400 if you want custom handling
        // options.SuppressModelStateInvalidFilter = true;
    });

---

When you might not want the default behavior

• You need custom validation flows
  If you always want to return a specific error shape or log extra context before returning, the automatic 400 may be too opinionated. You can:
  • Keep [ApiController] and suppress only the part you don’t want:

    options.SuppressModelStateInvalidFilter = true;

    Then manually handle ModelState inside actions or globally via filters/middleware.
• You don’t use attribute routing
  [ApiController] expects attribute routing. If you rely on conventional routing (uncommon for modern APIs), either migrate to attribute routing or don’t use [ApiController].
• Non-API controllers
  For MVC controllers that return views, don’t use [ApiController] (it’s intended for APIs).

---

Common gotchas & tips

• Multiple [FromBody] parameters aren’t allowed
  HTTP requests have a single body. If you need multiple inputs, combine them into one DTO.
• Explicit binding attributes still work (and can clarify intent)
  Even with inference, adding [FromQuery], [FromRoute], [FromHeader], [FromForm], [FromBody] can make your action signatures self-documenting.
• File uploads
  For multipart/form-data uploads, use [FromForm] and IFormFile/IFormFileCollection as needed; inference usually does the right thing, but being explicit can help.
• Global exception handling
  [ApiController] doesn’t replace exception handling. Use a global exception handler (UseExceptionHandler + mapping to ProblemDetails) to ensure consistent 5xx responses.

---

Bottom line

• For ASP.NET Core Web APIs, decorate controllers with [ApiController].
• It’s the idiomatic, recommended approach in modern ASP.NET Core and saves you from a lot of boilerplate while improving correctness and consistency.
• If you need to deviate, you can fine‑tune behaviors via ApiBehaviorOptions.

If you want, share a snippet of your controller or what behavior you’re aiming for (e.g., custom error shapes or logging), and I can help you configure the exact setup.