Spring АйО

👩‍💻 AI Agent-ы в Open Source разработке на Java Друзья, всем привет! Недавно вышла запись доклада, где наш эксперт, Михаил Поливаха, выступал на конференции AgenticConf с докладом "Axelix: Scaling Open Source with AI". Если вам интересно, как осознанно, на практике и без лишнего хайпа внедряются AI Agent-ы в процесс разработки (и где они не внедряются) - этот доклад для вас. Важно ещё и то, что исходный код ядра Axelix является Open Sourcе и лежит на GitHub, поэтому все детали можно увидеть своими глазами. Приятного просмотра! 😉 СМОТРЕТЬ НА YOUTUBE 😄 СМОТРЕТЬ В VK ВИДЕО

☕️ Дождались. 30 лет без встроенной поддержки JSON Согласитесь, сейчас ну нет Java-проекта, в котором нет Jackson, Gson или JSON-B. Даже если нужно просто прочитать небольшой JSON-файл или отправить простой HTTP-запрос, почти всегда приходится подключать стороннюю библиотеку. И это реально странно. Не находите? У нас в стандартной библиотеке Java есть: – HTTP-клиент – Работа с XML – ZIP, Base64, криптография, регулярные выражения… НО САМОГО РАСПРОСТРАНЕННОГО ФОРМАТА ОБМЕНА ДАННЫМИ - НЕТ. Наконец-то, в OpenJDK решили наконец закрыть этот момент. Итак, в JDK 28 предложен JEP 540: Simple JSON API. Это небольшой стандартный API для чтения, записи и построения JSON без сторонних зависимостей. Спасибо. Но суть не в том, чтобы заменить Jackson. Скорее наоборот. Jackson останется лучшим выбором для Spring-приложений, сложной сериализации, аннотаций, стриминга и огромной экосистемы. Новый API решает другую задачу. Представим, что мы пишем: - небольшую CLI-утилиту; - агент; - библиотеку; - Gradle-плагин; - простой микросервис. Вместо того чтобы добавлять ещё одну зависимость только ради пары строк JSON, можно будет воспользоваться тем, что уже есть в JDK. Теперь интересно другое. Если JEP примут, что вы выберете в новом проекте? 👍 Стандартный JSON API из JDK. 🔥 Jackson, потому что он всё равно намного мощнее. 🔗 JEP 540: https://openjdk.org/jeps/540

🔔 У Spring АйО снова пары: митап для Java-разработчиков 20 августа приглашаем Java-разработчиков и тимлидов вернуться в универ. Вместе с экспертами Spring АйО и PVS-Studio обсудим, как меняются привычные инструменты и подходы к разработке. В программе: ☑️ Spring и ИИ Посмотрим, как ИИ-агенты влияют на разработку Spring, создание фич и сам фреймворк. ☑️ Внутреннее устройство компилятора Разберемся, что происходит с исходным кодом до появления байткода: от лексического анализа и парсинга до построения AST. А затем посмотрим, как это используется в статическом анализе и поиске проблем безопасности. ☑️ ИИ и реальные системы Поговорим о том, почему сгенерированный Spring Boot-сервис еще не готов к продакшену и какие задачи остаются за инженером. 📅 Когда: 20 августа, 19:00 📍 Где: кампус Центрального университета, Москва, ул. Гашека, 7 🔗 Регистрация, программа и информация о спикерах Попасть в кампус можно до 19:30. На входе понадобится паспорт или водительские права.

👩‍💻 Яблочники (только те, что на Intel), плохие новости В OpenJDK появился JEP 541, предлагающий прекратить поддержку macOS x64 начиная с JDK 28. Когда-то Intel Mac был практически эталонной машиной для Java-разработчика. Но мир меняется. После перехода Apple на собственные процессоры прошло уже несколько лет, и сегодня подавляющее большинство новых Mac выпускается на Apple Silicon. В целом то понятно, что поддержка двух архитектур одновременно это не только дополнительные сборки. Это ещё и: • отдельное тестирование; • поддержка CI; • исправление платформенных багов; • ресурсы разработчиков OpenJDK. В какой-то момент цена такой поддержки становится выше, чем её польза. Для большинства разработчиков эта новость никак не повлияет ни на что. Но если вы, всё ещё работаете на Intel Mac: платформа постепенно переходит в категорию legacy. А помните, что несколько лет назад многие сомневались, сможет ли ARM стать основной архитектурой для профессиональной разработки. Сегодня вопрос звучит уже иначе. Не «стоит ли переходить на Apple Silicon?», а «сколько ещё будут поддерживать Intel?». 🔗 JEP 541: https://openjdk.org/jeps/541

🚨 У RestTemplate истекает срок годности Команда Spring официально перевела RestTemplate в статус @Deprecated в Spring Framework 7.1. 😄 Пора переходить на RestClient? Или еще подождем? Хронология: • Spring 6.1 — появился RestClient; • Spring 7.1 — RestTemplate официально помечен как @Deprecated; • Spring 8.0 — RestTemplate планируют удалить. Для многих это конец целой эпохи. RestTemplate появился ещё в 2009 году вместе со Spring 3 и больше 15 лет был стандартным способом отправлять HTTP-запросы. Но его API перестал масштабироваться. Каждая новая фича требовала десятков перегруженных методов (getForObject(), exchange(), postForEntity()...), из-за чего развивать клиент становилось всё сложнее. Видимо, именно поэтому Spring сделал ставку на RestClient — современный модный молодежный fluent API, который уже используется как основной синхронный HTTP-клиент. ❗️Это не значит, что завтра бежим переписывать все проекты. Но если вы вдруг на следующей неделе планировали писать новый сервис, использовать RestTemplate уже не надо. Если же поддерживаете существующий код, стоило бы запланировать постепенную миграцию, пока она не превратилась в обязательную. Много кто у нас на RestClient сидит? 👍 Да, перешли. 🤔 Пока остаёмся на RestTemplate. 🔥 Для синхронных вызовов давно используем WebClient. 🔗 Release Notes Spring Framework 7.1: https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-7.1-Release-Notes

Spring АйО pinned «Друзья, всем привет! Наконец-то, вышла запись нашего митапа с Aston! На митапе выступали эксперты сообщества: - Михаил Поливаха. Тема: устройство Spring AOP и проксирования под капотом в Spring Framework (с примерами из Axelix OSS). - Евгений Сулейманов.…»

🔥 Aston & Spring АйО Друзья, всем привет! Наконец-то, вышла запись нашего митапа с Aston! На митапе выступали эксперты сообщества: • Михаил Поливаха. Тема: устройство Spring AOP и проксирования под капотом в Spring Framework (с примерами из Axelix OSS). • Евгений Сулейманов. Тема: правильная работа с Dead Letter Topics в современных production системах. Приятного просмотра! 😉 СМОТРЕТЬ НА YOUTUBE

⚡️ Spring играет в оптимизацию В Spring Framework 7.1 изменили поведение, которое большинство разработчиков даже не замечало. Раньше при запуске приложения Spring автоматически проверял, доступен ли JAXB, и, если находил его, регистрировал XML-конвертер. Даже если ваше приложение вообще НИКОГДА не работало с XML. Теперь это поведение изменили. Для серверных приложений Spring больше не подключает JAXB автоматически. Если XML действительно нужен, то его придётся включить явно. Вот. Много профита дает? Надо тестить. Spring цифр не дает. We noticed that the JAXB message converter can consume a lot of CPU resources at runtime, even if XML isn't being used by the application. В любом случае автоматическое определение компонентов не бесплатно само по себе. Это: - дополнительные проверки при старте; - лишняя работа ClassLoader; - расход CPU; - усложнение процесса инициализации. По отдельности это мелочи. Но именно из таких мелочей складывается время запуска современных приложений. Раньше фреймворк старался угадать, что может понадобиться разработчику. Теперь всё чаще действует другой принцип: Не делай ничего, пока тебя об этом явно не попросили. И, кажется, это правильно. 🔗 Источник: Spring Framework 7.1 Release Notes https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-7.1-Release-Notes

🍃 AI пишет лучше разработчиков, Баг в JVM сломал Kafka, JavaScript победил Java | Spring АйО Подкаст №70 😉 СМОТРЕТЬ НА YOUTUBE 😄 СМОТРЕТЬ В VK ВИДЕО 🥰 СМОТРЕТЬ НА RUTUBE 🗯 СЛУШАТЬ НА ЯНДЕКС.МУЗЫКЕ 🤩 СЛУШАТЬ НА SPOTIFY 🤩 СЛУШАТЬ НА APPLE PODCASTS 💬 Аудио версию подкаста можно найти в комментариях

🧑‍💻 Победить Hibernate в тестах. Сможем? В рамках первого потока Spring АйО Акакдемии был поднят интересный вопрос: Возможно ли, каким-то образом, обнаружить в процессе тестирования, что Hibernate под капотом делает что-то страшное? На деле вопрос очень интересный и практичный. Мы решили оформить его в небольшую статью в виде размышлений о том, какие вещи, в теории, можно попробовать. Данная статья не является исчерпывающим материалом, а больше аккумулирует опыт и рассказывает - что, на практике, имеет смысл, а что не очень. На деле, одними тестами тут обойтись будет тяжело. Лучше всего использовать комбинированный подход. 😎 Приятного чтения! 📎 Статья на Хабр: https://habr.com/ru/companies/spring_aio/articles/1068176/

⚡️ Можно ли запретить AI-агенту ломать архитектуру Spring-приложения? Одних инструкций в AGENTS.md и Skills недостаточно. Агенту нужны инструменты, которые проверят результат и помогут найти ошибку. В новом видео разбираем это на примере ArchUnit: агент нарушит архитектуру Spring-приложения, получит упавший тест и самостоятельно исправит код. Но видео не про ArchUnit. Оно про то, как тесты, линтеры и анализаторы создают для AI-агента обратную связь и помогают ему работать качественнее. 😉 СМОТРЕТЬ НА YOUTUBE 😄 СМОТРЕТЬ В VK ВИДЕО 🥰 СМОТРЕТЬ НА RUTUBE

👀 Как понять, на чём тормозит запуск Spring Boot Нередка ситуация, когда приложение стало запускаться заметно дольше, а в логах все ок. Может быть такое, что время уходит на создание бинов, загрузку данных или подключение к внешним сервисам. Чтобы найти узкое место, Spring предоставляет интерфейс ApplicationStartup. Есть три стула основные реализации: – DefaultApplicationStartup. Используется по умолчанию и фактически ничего не записывает. – BufferingApplicationStartup. Хранит события запуска в памяти. Удобен для локальной диагностики, тестов и просмотра через Actuator. – FlightRecorderApplicationStartup. Передаёт данные в Java Flight Recorder для более глубокого профилирования. Для быстрого анализа можно подключить буферизацию: SpringApplication app = new SpringApplication(Application.class); app.setApplicationStartup( new BufferingApplicationStartup(2048) ); app.run(args); И открыть эндпоинт в настройках: management.endpoints.web.exposure.include=startup После запуска временная шкала будет доступна по адресу: GET /actuator/startup В ответе можно увидеть продолжительность отдельных этапов, их иерархию и имена создаваемых бинов: { "duration": "PT0.000754S", "startupStep": { "name": "spring.beans.instantiate", "tags": [ { "key": "beanName", "value": "specialService" } ] } } У эндпоинта есть важная особенность: – GET возвращает текущий снимок временной шкалы; – POST возвращает снимок и очищает буфер. Можно добавлять и собственные этапы. Например, отдельно измерять подключение к базе данных: StartupStep step = applicationStartup.start("app.database.connect"); try { step.tag("database", "main"); connectToDatabase(); } finally { step.end(); } Такие этапы появятся рядом со стандартными событиями Spring. Это особенно полезно, когда во время инициализации выполняются миграции, прогреваются кэши, загружаются модели или создаются подключения к внешним системам. Для продолжительного и более детального профилирования лучше использовать FlightRecorderApplicationStartup вместе с JFR и Java Mission Control. Короче: – нужен быстрый снапшот запуска - юзаем BufferingApplicationStartup; – нужен глубокий анализ JVM - юзаем FlightRecorderApplicationStartup; – нужна диагностика бизнес-инициализации, тогда добавляем собственные StartupStep. Как-то так 🤓 🔗 Фул статья: https://habr.com/ru/companies/spring_aio/articles/1066976/

🤖 AI-агент просил разрешить правку файла проекта. А сам добавил SSH-ключ злоумышленника Ситуация. Вы клонируете репозиторий, просите AI-агента настроить проект и видите обычное подтверждение: Разрешить изменение `project_settings.json`? Нажимаете «Разрешить». Только агент записывает данные не в настройки проекта, а в ~/.ssh/authorized_keys. Если SSH доступен извне, добавленный ключ может открыть злоумышленнику вход на компьютер без пароля. Исследователи Wiz назвали эту атаку GhostApproval и воспроизвели её сразу в шести AI-инструментах: – Amazon Q Developer – Claude Code – Augment – Cursor – Google Antigravity – Windsurf Схема-то простая и рабочая) Вредоносный репозиторий содержит чисто символическую ссылку, файловую «переадресацию». Файл выглядит как project_settings.json, но на самом деле ведёт к ~/.ssh/authorized_keys или ~/.zshrc. README просит агента изменить типа «настройку проекта». Агент выполняет инструкцию, следует по ссылке и пишет уже за пределами репозитория. Ну красота же. Самое неприятное то, что в в тестах Windsurf и Amazon Q успевали изменить файл ещё до подтверждения пользователя. Augment выполнял чтение и запись вообще без запроса. А в Claude Code агент распознал реальный файл, но человеку всё равно показал безобидное имя project_settings.json. AWS, Cursor и Google выпустили исправления. В актуальных версиях Claude Code есть предупреждение о таких ссылках. На момент публикации исследования Wiz не получила подтверждения исправлений от Augment и Windsurf. Мораль сей басни здесь интереснее самой уязвимости: кнопка «Разрешить» не защищает разработчика, если интерфейс показывает ему не то действие, которое действительно выполнит агент. Поэтому незнакомые репозитории лучше открывать в контейнере или виртуальной машине, а перед запуском агента проверить файловые ссылки командой: find . -type l -ls 💡 Источники: – исследование Wiz, – бюллетень AWS, – официальное исправление Cursor. Они нас погубят... 🙃

🤖 ИИ выдумал уязвимости SQLite. Они попали в официальные базы Шесть новых уязвимостей SQLite оказались выдуманными. Но до того, как это выяснилось, они успели получить номера CVE, попасть в Национальную базу уязвимостей США и системы автоматического анализа безопасности. Одной из них даже присвоили оценку 9,8 из 10 по шкале критичности CVSS. Почти максимальная опасность. Это когда возможна утечка данных, отказ в обслуживании и удалённое выполнение кода. Представьте реакцию команды 😅 Сканер находит критическую уязвимость в зависимости, сборка краснеет, релиз останавливается, разработчики начинают искать способ обновиться или закрыть дыру. А дыры... Не существует) История началась с того, что неизвестный автор опубликовал на GitHub более 50 описаний уязвимостей. Вот тот самый репо. Исследователи JFrog решили проверить шесть CVE, якобы обнаруженных в SQLite. Они собрали заявленные версии базы в изолированных контейнерах, запустили примеры эксплуатации под AddressSanitizer и изучили исходный код. Результат получился впечатляющим: – упомянутых функций не существовало в заявленных версиях SQLite; – номера строк указывали за пределы файлов; – описанные исправления никогда не вносились; – часть PoC содержала невалидный SQL; – ни один из примеров не вызвал обещанную ошибку. После более широкого аудита выяснилось, что из 55 опубликованных описаний 54 были полностью выдуманы. Ещё одно основывалось на реальном баге, но содержало непроверенные CVE-данные. JFrog предполагает, что описания были сгенерированы при помощи LLM. С этим уже согласились и разработчики SQLite и на официальной странице проекта шесть CVE помечены как несуществующие баги и вероятные галлюцинации ИИ. Сами записи начали удалять из баз. И вот здесь начинается самое интересное. Во многих компаниях новые CVE автоматически попадают в сканеры, CI, отчёты и задачи для разработчиков. А – автоматизиция. Например, в TELUS Dependabot постоянно проверяются зависимости и при обнаружении уязвимости создаёт предупреждение и рекомендует исправляющий PR. В Synergy проверки Dependabot автоматически запускаются при создании каждого PR. А JFrog Xray можно настроить так, чтобы по данным об уязвимости система создала задачу в Jira, запретила скачивание библиотеки или остановила сборку. Поэтому ошибочная CVE, прошедшая проверку используемой платформы, способна превратиться не просто в строчку в базе, а в настоящий PR, задачу для разработчика или заблокированный релиз. Получается почти идеальный цикл: 1. ИИ придумывает уязвимость. 2. Автоматическая система принимает её за настоящую. 3. Другой ИИ-агент пытается найти несуществующую функцию и написать для неё патч. 4. Команда тратит вполне настоящее рабочее время. Походу, одного номера CVE и высокой оценки теперь недостаточно. Для свежих уязвимостей придётся проверять подтверждение от разработчиков проекта, ссылку на исправляющий коммит, затронутые версии и воспроизводимость PoC. Добро пожаловать в эпоху, когда security-сканеру тоже нужен фактчекинг 🙂 📎 Расследование JFrog: https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/ 📎 Позиция SQLite: https://sqlite.org/cves.html

🛠 Axelix вышел в GA Почему этот бин вообще создался? Откуда приехало значение property? Кто съел все соединения из пула? И где мы опять поймали N+1? В такие моменты мы идём в логи, подключаем дебаггер и начинаем разбираться во внутренностях Spring. Ну или просто перезапускаем приложение, вдруг больше не повторится. Axelix появился как раз для таких расследований. Он подключается к работающим Spring Boot-приложениям и показывает, что происходит с бинами, конфигурацией, транзакциями, кэшами и scheduled-задачами. А ещё ищет известные проблемы и сомнительные настройки — те самые костыли, которые Spring-разработчики собирают в проде уже много лет. И вот теперь Axelix вышел в GA — состоялся релиз версии 1.0.0. До него были milestone-версии, которые успели попробовать несколько десятков команд. Исходный код проекта открыт под лицензией LGPL-3.0. Версию 1.0.0 уже можно использовать в продакшне, хотя разработчики советуют не спешить и для начала обкатать её на dev-окружении. Что, в общем-то, звучит разумно. Если хочется узнать, зачем появился Axelix и какой путь проект прошёл до первого стабильного релиза, об этом подробно рассказал Михаил Поливаха — технический лидер Axelix и эксперт Spring АйО. 📎 Мотивация создания продукта: https://habr.com/ru/companies/spring_aio/articles/1065202/ 📱 Канал Axelix: http://t.me/axelix_official 👩‍💻 Исходный код на GitHub: https://github.com/axelixlabs/axelix

🔨 Как Kafka сломала JVM Казалось бы, что может пойти не так при обычном вызове KafkaTemplate.send()? Метод возвращает Future, ошибки обрабатываются в коллбэке, всё выглядит ок. Но после сетевого сбоя приложение начинает бесконечно выбрасывать IllegalMonitorStateException, помогает только перезапуск. В статье от нашего участника Spring АйО Академии, Евгения Рудикова, развернулся настоящий технический детектив: корутины, скрытая блокировка в Kafka Producer, вложенные synchronized, JIT-компиляция, CodeCache и баг OpenJDK. Разбираемся, как и в JVM могут быть баги, которые проявляются в определённых условиях, и почему библиотечный код стоит заранее считать потенциально блокирующим. 📎 Полный текст: https://habr.com/ru/companies/spring_aio/articles/1064528/

👩‍💻 Новиночка от JetBrains JetBrains выпустила в ранний доступ JetBrains Context. Он помогает ИИ-агентам быстрее разбираться в больших проектах. Обычно перед выполнением задачи агент долго изучает код (ищет нужные файлы, читает классы и проверяет связи между модулями). Новая тула заранее создаёт индекс кодовой базы и помогает сразу находить подходящие участки кода. Работает с Claude Code, Codex CLI и Junie CLI. Поддерживается поиск сразу по нескольким репозиториям, даже если они не скачаны локально. По тестам JetBrains инструмент обещает сократить: ☑️количество шагов агента до 68%; ☑️время выполнения задачи до 59%; ☑️расходы до 48%. Доступно подписчикам JetBrains AI без дополнительной оплаты и не расходует AI-квоту. Что на рынке уже есть: ☑️ Augment Context Engine самый близкий аналог. Работает с разными агентами через MCP и также поддерживает несколько репозиториев. ☑️ Sourcegraph более мощное решение для крупных компаний с сотнями репозиториев. Умеет искать код, зависимости, изменения и историю коммитов. Есть self-hosted-версия. ☑️ GitHub Copilot тоже индексирует репозитории, но в основном работает внутри GitHub и Copilot. Получается: ☑️ JetBrains Context — простой старт для пользователей JetBrains AI; ☑️ Augment — универсальный вариант для разных агентов; ☑️ Sourcegraph — решение для крупных корпоративных проектов; ☑️ GitHub — встроенный инструмент для команд на Copilot. Наверное, одного мощного ИИ-агента уже недостаточно. Ему ещё нужен отдельный инструмент, который быстро объяснит, как устроен проект. Для больших Spring-проектов с множеством модулей и внутренних API в целом это может дать эффект. Но надо тестить. 🧐 Годно?

🍃 Новый HTTP-метод, IPv6 бесперспективен, QUERY удалят | Spring АйО Подкаст №69 😉 СМОТРЕТЬ НА YOUTUBE 😄 Чуть позже... 🥰 СМОТРЕТЬ НА RUTUBE 🗯 СЛУШАТЬ НА ЯНДЕКС.МУЗЫКЕ 🤩 СЛУШАТЬ НА SPOTIFY 🤩 СЛУШАТЬ НА APPLE PODCASTS 💬 Аудио версию подкаста можно найти в комментариях

⚙️ В HTTP появился метод QUERY. Пора прощаться с POST /search? У бэкенд-разработчиков много лет был довольно неловкий выбор. Пока фильтров мало, используем GET: GET /orders?page=2&status=PAID&sort=createdAt,desc Потом поиск усложняется. Появляются диапазоны дат, группы условий, вложенные фильтры. Query string постепенно превращается в плохо читаемый DSL. Заодно приходится учитывать ограничения на длину URI и то, что адрес запроса может попасть в логи. Обычно в этот момент появляется такой эндпойнт: POST /orders/search Content-Type: application/json { "status": ["PAID", "SHIPPED"], "createdAt": { "from": "2026-06-01", "to": "2026-06-30" }, "customer": { "country": "NL" } } Решение рабочее. POST вообще не ограничен созданием ресурсов. Сервер может обрабатывать его тело по собственной семантике. Проблема в другом: на уровне HTTP POST считается потенциально небезопасным и не идмептентным. Прокси, клиенты и другая инфраструктура не знают, что наш /search только читает данные. Такой запрос нельзя автоматически повторять или полноценно кэшировать без дополнительных договоренностей. Передать тело в GET технически возможно. Но RFC 9110 говорит, что у содержимого GET-запроса нет общепринятой семантики. Некоторые серверы и промежуточные узлы могут отклонить такой запрос. Среди причин упоминаются даже атаки класса request smuggling. В июне 2026 года IETF опубликовала RFC 10008 с новым методом QUERY: QUERY /orders HTTP/1.1 Content-Type: application/json Accept: application/json { "status": ["PAID", "SHIPPED"], "total": { "min": 100, "max": 1000 } } QUERY предназначен для запросов, описание которых передается в теле. Формат может быть любым, если он обозначен через Content-Type: JSON, SQL, JSONPath или собственный язык фильтрации. Спецификация закрепляет за QUERY три свойства: - safe - клиент не запрашивает изменение состояния целевого ресурса - idempotent - запрос можно безопасно повторить - cacheable - ответ разрешено кэшировать Для кэша есть отдельное правило: ключ должен учитывать тело запроса и связанные с ним метаданные. Поэтому существующие CDN и reverse proxy не начнут кэшировать QUERY сами по себе. Им потребуется поддержка нового метода. QUERY также умеет работать с conditional requests. А сервер может сообщить о допустимых форматах через новый заголовок Accept-Query. 👩‍💻 Что со Spring? В актуальном Spring Framework полноценной поддержки QUERY пока нет. Проблема находится именно на уровне фреймворка: в RequestMethod отсутствует такое значение, поэтому обычный @RequestMapping нельзя привязать к QUERY. Обойти ограничение можно через functional endpoints, собственный HandlerMapping или ручную проверку метода. Для нового стандарта это слишком много самодельной инфраструктуры. Сейчас открыт PR с поддержкой RFC 10008. Команда Spring рассчитывает подготовить ее к Spring Framework 7.1, который ожидается в ноябре 2026 года. Точная версия пока не гарантирована. Так что переписывать все POST /search сегодня рано. Ждем нормальной поддержки в Spring, клиентах и прокси. Потом уже можно будет с чистой совестью бежать менять поисковые POST-запросы на QUERY. RFC 10008: https://www.rfc-editor.org/info/rfc10008/ Spring Framework PR: https://github.com/spring-projects/spring-framework/pull/34993

🔑 Натуральные ключи в БД. Последний раз объясняю! Каждый разработчик хотя бы раз задумывался: "Зачем создавать отдельный ID, если в таблице уже есть уникальное поле? Email, номер паспорта, GAV-координаты — всё это отлично идентифицирует запись, понятно выглядит и даже несёт полезную информацию". Кажется, что натуральный ключ - вполне логичное решение. Но только до тех пор, пока бизнес не просит изменить правила. Вчера поле было уникальным, сегодня - уже нет. А вместе с ним начинает разваливаться всё, что на него завязано. В новой статье разбираем небольшой кейс, где натуральный ключ казался очевидным выбором ровно до одной фразы от бизнеса. Если вы когда-нибудь хотели сделать email или другое бизнес-поле Primary Key, рекомендуем прочитать статью до того, как это решение попадёт в прод. 📎 Подробнее в статье: https://habr.com/ru/companies/spring_aio/articles/1062754/