Почему некоторые компании (например, банки) отправляют абсолютно все запросы методом POST?

Почему банки предпочитают POST?

Основная причина — безопасность и конфиденциальность данных. При использовании GET все параметры запроса (например, номер счёта, сумма перевода) попадают в URL. URL сохраняется в истории браузера, в логах прокси-серверов и веб-серверов, а также может быть закэширован. В банковской сфере это недопустимо, так как даже косвенная информация может быть использована злоумышленниками.

POST отправляет данные в теле запроса, которое не логируется большинством систем по умолчанию и не сохраняется в истории. Это снижает поверхность атаки и соответствует требованиям регуляторов (например, PCI DSS).

Технические ограничения GET

• Длина URL ограничена (обычно 2048 символов в старых браузерах), что не подходит для больших объёмов данных.
• GET-запросы кэшируются браузерами и промежуточными серверами, что может привести к устаревшим данным или утечке информации.
• GET не должен изменять состояние сервера, но в банковских операциях почти всегда есть побочные эффекты (списание, зачисление).

Практический пример

// Небезопасно: данные в URL
fetch('/api/transfer?from=123&to=456&amount=1000')

// Безопаснее: данные в теле
fetch('/api/transfer', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ from: '123', to: '456', amount: 1000 })
})

Компромисс и идемпотентность

Использование POST для всех операций нарушает принципы REST, где GET должен быть безопасным и идемпотентным. Чтобы избежать дублирования транзакций при повторной отправке, банки добавляют уникальные идентификаторы запросов (idempotency keys) и проверяют их на сервере.

Вывод

POST для всех запросов — это осознанный выбор в средах, где безопасность и конфиденциальность важнее семантической чистоты API. Такой подход оправдан в банковских системах, медицинских приложениях и других доменах с высокими требованиями к защите данных, но требует дополнительной работы по обеспечению идемпотентности и корректной обработки ошибок.