REST

REST (Representational State Transfer) is an architectural style for designing networked applications, introduced by Roy Fielding in 2000.

REST Constraints

1. Client-Server — Separation of UI and data storage
2. Stateless — Each request contains all needed information
3. Cacheable — Responses must define cacheability
4. Uniform Interface — Consistent way to interact with resources
5. Layered System — Architecture can have intermediate layers
6. Code on Demand (optional) — Server can send executable code

REST Resource Model

Resource (Entity)
    |
    +--> Representation (JSON/XML)
    |
    +--> URI (Unique Identifier)
    |
    +--> Methods (GET, POST, PUT, DELETE)

REST Example

GET    /api/products         → List all products
GET    /api/products/123     → Get product 123
POST   /api/products         → Create a product
PUT    /api/products/123     → Update product 123
DELETE /api/products/123     → Delete product 123

REST Maturity Model (Richardson)

Level	Description	Example
0	Single URI, single method	SOAP over HTTP
1	Multiple URIs, single method	Actions on resources
2	HTTP methods + status codes	Standard REST
3	HATEOAS, discoverability	Full REST

Principles

• Stateless communication
• Client-server separation
• Cacheable responses
• Uniform interface

HTTP Methods

• GET: Read (idempotent, safe)
• POST: Create
• PUT: Full update (idempotent)
• PATCH: Partial update
• DELETE: Remove (idempotent)

Status Codes

• 2xx: Success
• 3xx: Redirection
• 4xx: Client error
• 5xx: Server error

Key Points

• Understanding What Is REST is essential for production systems
• Always consider scalability and maintainability
• Test thoroughly before deploying to production
• Monitor performance and set up alerting

Common Patterns

1. Validation: Always validate input at the boundary
2. Error Handling: Use structured error responses
3. Logging: Log key events for debugging
4. Testing: Unit, integration, and load tests
5. Documentation: Keep docs updated with code changes