Skip to content
IRC-CodingIRC-Coding
RESTfulHTTP methodsStatus codesIdempotencyStatelessnessCRUDAPI design

RESTful Design Principles: GET, POST, PUT, DELETE, PATCH

RESTful API design with HTTP methods, CRUD operations, status codes, idempotency, and statelessness explained.

S

schutzgeist

2 min read
RESTful Design Principles: GET, POST, PUT, DELETE, PATCH

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

  1. HTTP methods (GET, POST, PUT, DELETE, PATCH)
  2. URI conventions (resource-based)
  3. Status codes (2xx, 4xx, 5xx)
  4. REST conformance (Richardson Maturity Model)
  5. Idempotency rules
  6. Stateless architecture
  7. Content negotiation (Accept and Content-Type headers)
  8. JSON/XML as data formats
  9. Authentication (Bearer tokens, API keys)
  10. 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)

  1. What does “stateless” mean in REST? The server stores no session data—every request must be complete and self-contained.
  2. Which HTTP methods are idempotent? GET, PUT, DELETE.
  3. Difference between PUT and PATCH? PUT replaces an entire object, while PATCH modifies only specific fields.
  4. What does status code 201 mean? Resource created successfully.
  5. REST vs. SOAP? REST is lightweight and uses HTTP directly; SOAP is XML-based and heavyweight.
  6. How do you address a resource? Through a URI, for example /users/123.
  7. Security measures for REST APIs? HTTPS, token authentication, access control.
  8. Why is idempotency important? Retries due to network failures have no unintended side effects.

Key Resources

  1. https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design
  2. https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
  3. https://restfulapi.net/
  4. https://swagger.io/specification/
  5. https://www.howtographql.com/basics/1-graphql-vs-rest/
Back to Blog
Share:

Related Posts