REST Principles & Standard HTTP Methods

Building an API is easy. Building a good API is remarkably difficult. REST (REpresentational State Transfer) is a globally agreed-upon architectural design pattern. Following REST principles ensures that any developer in the world can intuitively guess how to interact with your codebase without reading a hundred-page manual.

1. The Six REST Architectural Constraints

For an API to be considered truly "RESTful," it must adhere to strict architectural rules. The most critical include:

• Client-Server Separation: The UI concerns are separated from data storage completely.
• Statelessness: Every HTTP request must contain *all* the information required to process it. The server cannot save session states in its memory between requests. This is why we use JWT tokens passed in the headers.
• Uniform Interface: Use standard HTTP verbs logically, and use resource-based URLs (e.g., /api/users/5 instead of /api/get-user-by-id?id=5).

2. Resource Naming Conventions (Crucial)

Endpoints should be modeled as Nouns (Resources) in their plural form. They should NEVER contain verbs (Actions).

3. The 5 Standard HTTP Verbs

In a true REST API, the action you wish to perform isn't in the URL; it relies entirely on the HTTP Method (Verb) used in the network request.

1. GET (Read)

Retrieves data. A GET request must be Idempotent and Safe. It should never alter the database. Running the same GET request 1,000 times must not change the server state.

[HttpGet("{id}")]
public IActionResult GetProduct(int id) { ... }

2. POST (Create)

Creates a brand new resource. It is NOT idempotent. If you send a POST request 5 times, it creates 5 new distinct rows in your database.

[HttpPost]
public IActionResult CreateProduct([FromBody] ProductDto product) { ... }

3. PUT (Full Update)

Replaces an existing resource entirely. It is Idempotent. If you send a PUT request 5 times, it overwrites the exact same data 5 times, leaving the server in the exact same state.

[HttpPut("{id}")]
public IActionResult UpdateProduct(int id, [FromBody] ProductDto updatedProduct) { ... }

4. PATCH (Partial Update)

Modifies only specific fields of a resource (e.g., just updating a user's phone number without transmitting the entire user object). Usually implemented using JSON Patch.

5. DELETE (Delete)

Removes a resource. Also idempotent; once a record is deleted, subsequent DELETE calls to it simply return a 404 (or 204 No Content).

4. Interview Mastery

Q: "What is the precise difference between PUT and POST in REST APIs?"

Architect Answer: "The primary difference lies in Idempotency. POST is used to create a new subordinate resource; the server determines the new URI (e.g., auto-incrementing the ID in the database). Because it is not idempotent, firing the same POST request multiple times creates multiple duplicate records. PUT, however, is idempotent. It is used to update or replace an existing resource at a specific, known URI (e.g., /api/users/5). Firing the exact same PUT request 100 times will result in the exact same state as firing it once."