Можно ли построить всю систему на POST?

Можно ли построить всю систему на POST

Технически да, можно. На практике — не стоит. Разберу почему и когда это может быть приемлемо.

Почему технически это возможно

POST метод HTTP позволяет передавать произвольные данные в теле запроса. Технически можно:

• Вместо GET использовать POST для чтения данных
• Вместо PUT использовать POST для обновления
• Вместо DELETE использовать POST для удаления

Это работает, потому что сервер обработает любой запрос так, как ему написано.

Практические проблемы

1. Нарушение REST принципов и семантики HTTP

HTTP методы имеют определённое значение:

• GET — получение данных (безопасная, идемпотентная операция)
• POST — создание ресурса (небезопасная, не идемпотентная)
• PUT — обновление (идемпотентная)
• DELETE — удаление (идемпотентная)

Если всё на POST, теряется информация о сути операции. Разработчик, видя POST, не знает, что на самом деле будет выполнено.

2. Кеширование не работает

GET запросы кешируются браузерами, прокси, CDN. POST не кешируется. Если вся система на POST:

• Каждый запрос идёт на сервер
• Нет никакого кеширования
• Производительность падает в 10-100 раз

3. Безопасность

• GET должны быть идемпотентны и безопасны (без побочных эффектов)
• Если читаешь данные через GET, её можно вызвать несколько раз без проблем
• POST не идемпотентен — повторный вызов может создать дубликат

Если построишь чтение на POST, то каждый f5 или автоматический повтор при сбое может создать проблемы.

4. Инструменты не работают

• Curl, Postman, браузер и другие инструменты ожидают конкретное поведение методов
• Если реализуешь чтение через POST, инструменты "запутаются"
• Невозможно просто открыть ссылку в браузере

5. Мобильные приложения и системы

• Кокпит IoT устройств часто кешируют GET и не кешируют POST
• Load balancer'ы могут переслать запрос по-разному в зависимости от метода
• Firewall правила могут отличаться для GET и POST

6. Масштабируемость

• Нельзя использовать статические CDN (например, CloudFlare)
• Каждый запрос должен доходить до application server'а
• Сложнее горизонтально масштабировать систему

Когда это может быть приемлемо

1. RPC стиль API (GraphQL, JSON-RPC)

Некоторые API намеренно используют POST для всех операций:

POST /api/query
{
  "query": "{ user(id: 1) { name, email } }"
}

Это нормально, потому что:

• Ясно обозначена архитектура (RPC, не REST)
• Клиенты это ожидают
• Работает для сложных операций с множественными зависимостями

2. Защита от простого перебора

Если боишься атак на перебор (brute-force), можно потребовать POST для критичных операций. Но это очень слабая защита.

3. Система без стандартных HTTP клиентов

Если система полностью замкнута (только собственные приложения с собственными клиентами), можно делать как угодно. Но это не рекомендуется даже в этом случае.

Правильный подход

REST архитектура — это стандарт:

GET    /api/users          — получить список пользователей
GET    /api/users/123      — получить конкретного пользователя
POST   /api/users          — создать нового пользователя
PUT    /api/users/123      — обновить пользователя
DELETE /api/users/123      — удалить пользователя

Это позволяет:

• Использовать все инструменты
• Кешировать GET
• Быть идемпотентным где нужно
• Легко интегрироваться

Вывод

Можно построить систему на POST? Да. Стоит ли? Нет. Это приведёт к:

• Плохой производительности (без кеширования)
• Проблемам с безопасностью
• Сложностям при интеграции
• Непредсказуемому поведению

Исключение: если ты сознательно выбираешь RPC архитектуру (GraphQL, JSON-RPC), то это уже не "система на POST", а система с другой парадигмой. Это нормально и задокументировано.