Skip to content
beginner Phase · REST API Development

Resource Design

Learn how to model your domain as RESTful resources.

40m
0 problems
Topic Progress 0%

Resource Hierarchy

Resource Relationships

Order
├── customer (belongs to)
├── items (has many)
│   └── product (references)
├── payment (has one)
└── shipping (has one)

Flat vs Nested Resources

# Flat (preferred for most cases)
GET /orders
GET /orders/123
GET /order-items?orderId=123

# Nested (for strict ownership)
GET /users/456/orders
GET /users/456/orders/123

Resource Design Patterns

Pattern Example When to Use
Single resource /products/123 Fetch specific item
Collection /products List/filter items
Sub-resource /products/123/reviews Owned resources
Action /products/123/archive Non-CRUD operations
Search /products/search?q=phone Search endpoints

Handling Actions in REST

When an action doesn't map to CRUD:

# Option 1: Use a sub-resource
POST /orders/123/cancel

# Option 2: Use HTTP method + status
PATCH /orders/123
{ "status": "cancelled" }

# Option 3: Use action endpoint
POST /orders/123/actions/cancel

Resource Field Design

{
  "id": "123",
  "name": "Wireless Mouse",
  "price": 29.99,
  "currency": "USD",
  "createdAt": "2025-01-15T10:30:00Z",
  "_links": {
    "self": "/products/123",
    "reviews": "/products/123/reviews"
  }
}

Include: IDs, core data, timestamps, links.
Exclude: Internal implementation details.

Design Patterns

Creational

  • Factory
  • Builder
  • Singleton
  • Prototype

Structural

  • Adapter
  • Decorator
  • Facade
  • Proxy

Behavioral

  • Observer
  • Strategy
  • Command
  • State

Best Patterns

  • Use appropriately
  • Don't over-engineer
  • Prefer composition
  • Follow SOLID principles

Key Points

  • Understanding Resource Design 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

Practice Problems

0 / 3 solved
Implement Resource Design

Design and implement a solution for Resource Design in a backend system. Consider scalability, error handling, and production readiness.

Solution 
// Resource Design implementation
// Key aspects: validation, error handling, logging, testing

public class ResourceDesign {
    // Production-ready implementation
}
Resource Design Edge Cases

Identify and handle edge cases for Resource Design. What happens under high load, with invalid input, or during failures?

Solution 
// Edge case handling:
// 1. Null/empty input -> validation
// 2. High load -> rate limiting, queuing
// 3. Failures -> retries, circuit breaker
// 4. Concurrent access -> locks, idempotency
Resource Design Testing Strategy

Write a testing strategy for Resource Design. Include unit tests, integration tests, and performance tests.

Solution 
// Test plan:
// - Unit: 80% coverage target
// - Integration: API contracts
// - Performance: latency, throughput
// - Chaos: failure injection

Quiz

1. When should you use nested resources?

Question 1 options

2. What should you exclude from API resource responses?

Question 2 options

3. What is a common mistake when implementing Resource Design?

Question 3 options

Flashcards

Question

When to use nested resources?

Click to reveal answer

Answer

When there is a strict ownership relationship (e.g., /users/123/orders)

Question

What goes in a resource response?

Click to reveal answer

Answer

IDs, core data, timestamps, links — exclude internal details

Question

Resource Design best practices

Click to reveal answer

Answer

Follow SOLID principles, write clean code, test thoroughly, document decisions, and monitor in production.

Revision Notes

Key Takeaways

  • 1. Design resources as nouns with clear relationships
  • 2. Use nested resources for strict ownership only
  • 3. Flat resources are simpler and preferred
  • 4. Include IDs, data, timestamps, links — exclude internals

Interview Tips

  • • Explain when to use nested vs flat resources
  • • Know how to design resource field responses

Cheat Sheet

Resource Design

  • Flat: /orders, /products (simpler, preferred)
  • Nested: /users/123/orders (strict ownership)
  • Actions: POST /orders/123/cancel or PATCH with status
  • Fields: id, data, timestamps, _links (no internals)