RESTful Design Principles
This article is a glossary entry on RESTful design principles—complete with exam questions and tags.
In a Nutshell
REST is an architectural approach to APIs built on HTTP, characterized by well-defined methods, resources, status codes, and statelessness.
Core Definition
REST is a lightweight, HTTP-based protocol for exchanging resources between client and server. It uses HTTP methods: GET (read), POST (create), PUT (replace), DELETE (remove), and PATCH (partial update). REST adheres to the statelessness principle, meaning every request must contain all necessary information; the server does not store session data. Idempotency plays a critical role: GET, PUT, and DELETE are idempotent (repeated execution has the same effect), while POST and PATCH are not. REST uses standardized status codes (such as 200 OK, 201 Created, 404 Not Found, 500 Server Error) to communicate outcomes.
Key Exam Points
- GET, POST, PUT, DELETE, PATCH: HTTP methods for CRUD operations
- REST is stateless—no session tracking on the server
- Idempotency: repeated requests have no additional side effects (e.g., with PUT)
- Resource-oriented URIs, for example /api/users/123
- HTTP status codes (200, 201, 404, 500, etc.)
- PATCH updates only portions of an object
- Security aspects: token-based authentication, HTTPS, CORS
- Interface documentation with OpenAPI or Swagger
Core Components
- HTTP methods (GET, POST, PUT, DELETE, PATCH)
- URI conventions (resource-based)
- Status codes (2xx, 4xx, 5xx)
- REST conformance (Richardson Maturity Model)
- Idempotency rules
- Stateless architecture
- Content negotiation (Accept and Content-Type headers)
- JSON/XML as data formats
- Authentication (Bearer tokens, API keys)
- OpenAPI/Swagger documentation
Practical Example
// Example: REST API for user management
GET /users → retrieve all users
POST /users → create a new user
GET /users/1 → retrieve user with ID 1
PUT /users/1 → replace user entirely
PATCH /users/1 → update specific fields only
DELETE /users/1 → remove user
Explanation: each method corresponds to a clearly defined action on a resource. The URI remains constant; the method determines the semantics.
Strengths and Weaknesses
Strengths
- Simple, easy to understand
- Uses standard protocols (HTTP)
- Platform and language agnostic
- Highly scalable
Weaknesses
- No built-in session management
- Can be inefficient with many API calls
- No standardization for complex operations
Common Exam Questions (with Short Answers)
- What does “stateless” mean in REST? The server stores no session data—every request must be complete and self-contained.
- Which HTTP methods are idempotent? GET, PUT, DELETE.
- Difference between PUT and PATCH? PUT replaces an entire object, while PATCH modifies only specific fields.
- What does status code 201 mean? Resource created successfully.
- REST vs. SOAP? REST is lightweight and uses HTTP directly; SOAP is XML-based and heavyweight.
- How do you address a resource? Through a URI, for example /users/123.
- Security measures for REST APIs? HTTPS, token authentication, access control.
- Why is idempotency important? Retries due to network failures have no unintended side effects.
Key Resources
- https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
- https://restfulapi.net/
- https://swagger.io/specification/
- https://www.howtographql.com/basics/1-graphql-vs-rest/



