Your First "Aha" Moment: You use APIs 100 times a day. You just didn't know it had a name.
1. You Already Know APIs. Here's Proof.
Open Zomato. Search "Pizza".
Did Zomato download a full website to your phone? No. Your phone has the app. The app just asked Zomato's server: "Give me pizza places"
Server replied with just this text:
[{"name":"Domino's","rating":4.2,"time":"30 min"}]
That URL is a Web API. That text is JSON.
Your app took that data and drew the screen. Website? Not involved.
โ MVC = For Humans
Browser โ Server
Server: "Here's a full HTML page"
Human reads it.
โ
API = For Apps
App โ Server
Server: "Here's raw data as JSON"
App builds its own screen.
2. Why Your Career Depends On This
2026 Job Reality:
- MVC Only: You maintain old company websites. 6-9 LPA. Competing with 10,000 freshers.
- API + MVC: You build backends for mobile apps, React, Angular, microservices. 12-20 LPA. Competing with 1,000 skilled devs.
Every startup, every MNC, every product has an app. Apps need APIs. No API skills = No callback.
3. Build Your First API Right Now - 3 Minutes
We're building the actual API Zomato's app would call.
Step 1: Create Project
VS โ New โ ASP.NET Core Web API โ Name: ZomatoBackend โ.NET 8 โ Check HTTPS, OpenAPI, Use controllers โ Create
Step 2: Add Restaurant Model
Delete WeatherForecast. Add folder Models โ Class Restaurant.cs:
public class Restaurant {
public int Id { get; set; }
public string Name { get; set; }
public double Rating { get; set; }
}
Step 3: Add Zomato Controller
Controllers โ Add โ API Controller Empty โ ZomatoController.cs:
[Route("api/[controller]")]
[ApiController]
public class ZomatoController : ControllerBase
{
[HttpGet("restaurants")]
public ActionResult> GetRestaurants()
{
var list = new List {
new Restaurant{Id=1, Name="KFC", Rating=4.1},
new Restaurant{Id=2, Name="Pizza Hut", Rating=4.3}
};
return Ok(list);
}
}
Step 4: Run It
Press F5. Swagger opens. Test GET /api/Zomato/restaurants.
You just did what Zomato's backend team does. You sent data to an app. No HTML. Just JSON.
Stop Here. Think. You now understand the #1 concept behind Uber, Instagram, Paytm, and every app on your phone.
In the next lesson, you'll learn the 4 words that control every API: GET, POST, PUT, DELETE. Master those + status codes = you can crack any backend interview.
Career-Killer Mistake: Building an API but inheriting from Controller instead of ControllerBase.
You load ViewBag, TempData, View() - 20KB of garbage per request. 1 million users = you just wasted 20GB RAM. That's a โน15,000/month Azure bill. Always use ControllerBase for APIs.
1. The Interview Theory: What, Why, How
What is a Web API? A URL endpoint that speaks HTTP and exchanges data, usually JSON, between software systems. It has no UI.
Why does it exist? Separation of Concerns. The backend team handles data + rules. Frontend/Mobile teams handle UI. They work parallel. Ship faster. Scale independently.
How does it work? HTTP Request-Response. Client sends Request with Method + URL + Headers + Body. Server sends Response with Status Code + Headers + Body.
2. The #1 Interview Question: "Explain Stateless"
Theory: HTTP is Stateless. The server treats every request as brand new. It has zero memory of your last request. No Session state.
Interviewer asks: "Then how does login work?"
Your Answer: "We don't use server sessions. On login, server gives client a signed JWT token. Client stores it. Every next request, client sends Authorization: Bearer <token> in the header. Server validates the token signature. No memory needed. This is why APIs can scale to millions - any server can handle any request."
This answer gets you the job. "We use Session" gets you rejected.
3. MVC vs API: The CTO View
| Decision | MVC | Web API |
| Who builds the UI? | Server. Sends HTML. | Client. Server sends JSON. |
| Base Class | Controller - has View() | ControllerBase - no View() |
| State | Server-side Session | Stateless. Client-side Token |
| Scaling Cost | Hard. Sticky sessions needed. | Easy. Any server handles any request. |
| 2026 Use Case | Internal Admin Panels | Mobile Apps, Public APIs, Microservices |
4. [ApiController] - Your Safety Net
This attribute saves your job. It does 3 things:
- Auto 400 Validation: Client sends
{ "rating": "five" } for double rating. Framework returns 400 Bad Request instantly. Your code never runs. No null crashes. No angry users.
- Binding Inference: Knows complex objects come from
[FromBody]. Primitives from query. Less code, fewer bugs.
- Problem Details Standard: All errors return RFC 7807 JSON. Mobile devs can parse it once and handle all errors. You look professional.
5. Return Types: Senior vs Junior Code
Theory: Your API is a contract. Swagger turns your C# into documentation for other teams.
// JUNIOR: Always 200 OK. Even if restaurant not found. Lying to client.
public Restaurant Get(int id) {...}
// MID-LEVEL: Can return 404. But Swagger shows return type "object".
// Frontend team must guess the shape. They will ping you at midnight.
public IActionResult Get(int id) {...}
// SENIOR: Swagger shows exact Restaurant model + you can return 404.
// Frontend runs one command: nswag. Gets full TypeScript client. Zero meetings.
public ActionResult Get(int id) {
var r = Find(id);
return r == null? NotFound() : r;
}
Career-Killer Mistake #2: public IActionResult Get()
Theory: Type erasure. The compiler and Swagger forget you return Restaurant.
Business Impact: Frontend can't auto-generate models. Manual integration takes 1 week. Your sprint fails. Your manager remembers. Use ActionResult<T>.
What's Next = Your First Promotion: You know WHAT an API is. Next lesson: HTTP Methods. GET, POST, PUT, DELETE. This is the grammar of APIs. Master this + status codes 200/201/404/500, and you can debug any backend issue and clear any interview. Click Next. Don't stop now.
No comments yet. Be the first to share your thoughts!