### 1. Client-Server Architecture The client and server are separate concerns: ``` ┌────────────────┐ ┌────────────────┐ │ Client │◄───────►│ Server │ ├────────────────┤ ├────────────────┤ │ - UI/UX │ │ - Data storage │ │ - User input │ │ - Business │ │ - Display │ │ logic │ └────────────────┘ └────────────────┘ ``` **Benefits:** - Client and server can evolve independently - Server can serve multiple client types (web, mobile, desktop) - Separation of concerns ### 2. Statelessness Each request contains all information needed to process it. The server doesn't store client state between requests. ```http # Bad: Relying on server-side session GET /api/cart/items # Good: Including all needed information GET /api/users/42/cart/items Authorization: Bearer eyJhbGc... ``` **Benefits:** - Easier to scale (any server can handle any request) - Simpler server logic - Better reliability ### 3. Resource-Based Everything is a **resource** identified by a URL. Resources are nouns, not verbs. ``` # Good: Resources (nouns) /api/products /api/products/42 /api/users/5/orders /api/categories/electronics/products # Bad: Actions (verbs) /api/getProducts /api/createUser /api/deleteProduct/42 ``` Resources represent entities in your domain: - Products - Users - Orders - Categories ### 4. Uniform Interface Use standard HTTP methods consistently: | Operation | HTTP Method | URL | Description | |-----------|-------------|-----|-------------| | List | GET | /products | Get all products | | Read | GET | /products/42 | Get one product | | Create | POST | /products | Create product | | Replace | PUT | /products/42 | Replace product | | Update | PATCH | /products/42 | Partial update | | Delete | DELETE | /products/42 | Delete product | ```csharp [ApiController] [Route("api/[controller]")] public class ProductsController : ControllerBase { [HttpGet] // GET /api/products public ActionResult> GetAll() { ... } [HttpGet("{id}")] // GET /api/products/42 public ActionResult GetById(int id) { ... } [HttpPost] // POST /api/products public ActionResult Create(Product p) { ... } [HttpPut("{id}")] // PUT /api/products/42 public IActionResult Update(int id, Product p) { ... } [HttpDelete("{id}")] // DELETE /api/products/42 public IActionResult Delete(int id) { ... } } ``` ```json { "question": "Which URL pattern follows REST principles for getting a specific product?", "options": ["/api/getProduct?id=42", "/api/products/42", "/api/product/get/42", "/api/fetchProduct/42"], "correct": 1 } ``` ### 5. Representations Resources can have multiple representations (JSON, XML, HTML). Clients specify their preference: ```http # Request JSON GET /api/products/42 Accept: application/json # Request XML GET /api/products/42 Accept: application/xml ``` The same resource, different representations: ```json // JSON representation { "id": 42, "name": "Widget", "price": 19.99 } ``` ```xml 42 Widget 19.99 ``` ### 6. HATEOAS (Hypermedia) Responses include links to related actions and resources: ```json { "id": 42, "name": "Widget", "price": 19.99, "_links": { "self": { "href": "/api/products/42" }, "update": { "href": "/api/products/42", "method": "PUT" }, "delete": { "href": "/api/products/42", "method": "DELETE" }, "category": { "href": "/api/categories/5" } } } ``` HATEOAS makes APIs self-documenting but adds complexity. Many APIs skip this principle.

REST Principles

REST Principles

What is REST?