DELETE /resource/{id}

API Design

Meaning

Defines an HTTP DELETE endpoint that removes a specific resource identified by its unique ID from a server-side data store. Addresses the need for a standardized, stateless way to express resource removal in RESTful APIs without relying on custom RPC-style operations. Triggered when designing or consuming CRUD APIs where individual resource deletion must be exposed as a first-class operation.

Primary Function

API endpoint design

Communicative Purpose

Enables clients to remove a specific resource by ID using a standardized HTTP verb, keeping deletion semantics aligned with REST conventions.

Pattern

DELETE /resource/{id}

Core Structure

DELETE /.../{...}

Função primária

API endpoint design

Propósito comunicativo

Enables clients to remove a specific resource by ID using a standardized HTTP verb, keeping deletion semantics aligned with REST conventions.

Situações de gatilho

Web API design: exposing resource deletion in a CRUD REST API Backend services: implementing remove-by-id handlers in Express, FastAPI, Spring, or similar frameworks API documentation: specifying DELETE routes in OpenAPI/Swagger specs

Contextos

RESTful web APIs, HTTP backends, OpenAPI specifications, CRUD microservices

Padrão

DELETE /resource/{id}

Estrutura central

DELETE /.../{...}

Slots de substituição

resource: string (plural noun for the resource collection), id: string or path parameter (unique identifier of the target resource)

Colocados típicos

HTTP status codes (200
204
404)
idempotency tokens
authentication middleware
path parameter binding
OpenAPI annotations

Substituições comuns

POST /resource/{id}/delete: used when DELETE is blocked by intermediaries or legacy clients PATCH /resource/{id} with {deleted: true}: soft delete pattern preserving the row DELETE /resource?id={id}: query parameter variant
less RESTful and harder to cache

Erros comuns

Returning 200 with a body instead of 204 No Content: violates REST convention and confuses clients expecting no payload Not handling 404 when resource does not exist: client cannot distinguish between successful no-op and error Using DELETE for soft deletes without documenting it: clients assume hard delete and lose data recovery options Forgetting idempotency: DELETE should be idempotent but some implementations decrement counters or trigger side effects on each call Exposing DELETE without authentication: allows unauthorized resource removal

Similar / contraste

PUT /resource/{id}: replaces the entire resource rather than removing it POST /resource/{id}/delete: non-standard verb usage, used when DELETE is blocked PATCH /resource/{id}: partial update, not deletion

Interferências

Coming from SOAP: may expect a separate DeleteResource operation in WSDL rather than an HTTP verb on a URL Coming from RPC frameworks: may use method-style URLs like /deleteResource?id=123 instead of verb-on-noun REST style Coming from GraphQL: may expect a mutation like deleteResource(id: ID!) rather than a separate HTTP endpoint

Família do chunk

GET /resource/{id}
POST /resource
PUT /resource/{id}
PATCH /resource/{id}
REST CRUD operations

Nuance

When NOT to use: when the resource has dependent children that need cascading cleanup handled atomically — prefer a batch or transactional endpoint Performance: DELETE is typically lightweight but may trigger cascading deletes, audit logs, or cache invalidation that add latency Boundary conditions: DELETE should be idempotent — calling it twice on the same resource should not error on the second call (return 404 or 204 consistently)

Efeito pragmático

Standardizes resource removal across clients and servers, enables caching proxies and middleware to understand intent, and makes API behavior predictable for consumers building CRUD interfaces.

Dica de memória

DELETE /resource/{id} is like crossing something off a list with a specific label — you point at the item by its tag and it's gone, no questions about which one.

Upgrade path

Batch DELETE endpoints (DELETE /resource?ids=1,2,3), soft delete patterns with PATCH, or async deletion with 202 Accepted and polling

Frequência: HighFormulaicidade: Semi-fixedPrioridade de aquisição: Recognition firstPrioridade de output: BothTag de espaçamento: Medium-term

Examples

from fastapi import FastAPI, HTTPException app = FastAPI() items = {"1": "apple", "2": "banana", "3": "cherry"} @app.delete("/items/{item_id}") def delete_item(item_id: str): if item_id not in items: raise HTTPException(status_code=404, detail="Item not found") del items[item_id] return {"deleted": item_id}

import org.springframework.web.bind.annotation.*; import org.springframework.http.ResponseEntity; import java.util.Map; @RestController @RequestMapping("/articles") public class ArticleController { private final Map<String, String> articles = Map.of("a1", "Hello", "a2", "World"); @DeleteMapping("/{id}") public ResponseEntity<Void> deleteArticle(@PathVariable String id) { if (!articles.containsKey(id)) { return ResponseEntity.notFound().build(); } articles.remove(id); return ResponseEntity.noContent().build(); } }