REST resources and methods

REST представляет domain nouns как resources с URL. HTTP methods выражают намерение; safety и idempotency направляют retries и caching.

| Method | Safe | Idempotent | Типичное применение | |--------|------|------------|---------------------| | GET | да | да | Чтение коллекции или элемента | | POST | нет | нет | Создание, команды, неидемпотентные действия | | PUT | нет | да | Полная замена resource по известному URI | | PATCH | нет | нет* | Частичное обновление (*часто делают идемпотентным) | | DELETE | нет | да | Удаление resource |

					GET    /orders?status=open          # список
GET    /orders/42                   # чтение
POST   /orders                      # создание (id назначает сервер)
PUT    /orders/42                   # полная замена
PATCH  /orders/42                   # частичное обновление
DELETE /orders/42                   # удаление
POST   /orders/42/cancel            # действие над sub-resource
				

Используйте множественное число (`/users`, не `/user`). Вложенность для containment (`/orders/42/items`), но избегайте глубоких деревьев, привязывающих клиентов к форме хранения. Предпочитайте ссылки в ответах или документированные relation fields вместо угадывания URL.

На интервью: обоснуйте выбор метода для create vs upsert, когда POST в коллекцию лучше PUT на client-chosen id, и как safety влияет на cache headers у GET.

Типовые ошибки: GET с изменением состояния, POST для всего подряд, глаголы в URL (`/getUser`), внутренние ключи БД без access control.

Компромисс: чистый REST против pragmatic RPC-style actions — документируйте action endpoints единообразно, когда domain verbs плохо ложатся на PUT/PATCH.

Чеклист:

• Существительные в URL; семантика в methods.
• GET не должен менять состояние.
• POST для create; PUT для полной замены по известному URI.
• Sub-resource actions явные и задокументированы.