GET /usersCollections should usually be plural nouns. The server returns a list of resources, often with pagination metadata.
Core REST API patterns for resource-oriented URLs, nested resources, and standard CRUD request examples.
Use nouns and predictable URL patterns for resources.
GET /usersCollections should usually be plural nouns. The server returns a list of resources, often with pagination metadata.
POST /usersPOST to a collection is the common create pattern. The server typically returns `201 Created` with the new representation or a location reference.
GET /users/{userId}Single resources usually live at a stable item URL.
PUT /users/{userId}PUT is typically used when the client sends a full replacement representation and expects idempotent behavior.
PATCH /users/{userId}PATCH is commonly used for partial updates so clients do not need to send the entire resource.
DELETE /users/{userId}DELETE removes a resource or marks it deleted. Many APIs return `204 No Content` on success.
GET /users/{userId}/ordersNested routes are useful when the child is clearly scoped to the parent. Avoid deep nesting when it hurts discoverability.
GET /users/{userId}/settingsA subresource can be appropriate when the related object has a stable identity within the parent.
Preferred route patterns vs less RESTful shapes.
Prefer: POST /invoices
Avoid: POST /createInvoiceREST routes are usually clearer when they describe resources and let the HTTP method express the action.
Prefer: /users
Avoid: /userPlural nouns make it easier to distinguish collections from single-resource lookups.
GET /users/123
GET /orders/ord_456Stable identifiers make URLs shareable and cache-friendly. Avoid path values that change often.
POST /payments/{paymentId}/refundsSome domain actions are best modeled as a resource creation under the target resource instead of a verb endpoint like `/refundPayment`.