API *

Безопасная разработка API на практике

Как устроен ваш цикл разработки приложений? Проверяются ли API на наличие уязвимостей до их публикации? И есть ли вообще для этого процесса какая-то методология?

Вместе с экспертом команды Вебмониторэкс, участвующим в совместной работе с ИСП РАН, подробно разберём, как выстроить эффективный процесс тестирования API, и чем отличаются различные его виды.

Когда? 23 апреля в 14:00

Спикер: Динко Димитров, руководитель продуктового направления, Вебмониторэкс

Зарегистрироваться на мероприятие 

Ждем вас на вебинаре!

Как писать REST API — 9 правил

REST API (Representational State Transfer Application Programming Interface) — это архитектурный стиль взаимодействия между клиентом и сервером через HTTP. Он определяет принципы построения API, обеспечивая стандартизированный и эффективный обмен данными между различными системами.

1. GET-запросы не должны что-то сохранять, удалять или изменять. Нельзя менять какие-либо данные на стороне сервера при GET-запросе. Почему? GET-запросы часто кешируются на стороне клиента.

2. POST запросы для загрузки/создания сущностей, PUT для изменения в сущности, а PATCH - для мелких изменений в сущности.

3. Наименование эндпоинтов. Должен присутствовать единый стиль, и желательно во множественном числе, ибо это более лаконичнее. Например, эндпоинт /users. Можно и единственное число использовать, но обосновано.

4. Иерархия. Нужно соблюдать единую иерархию для построения запросов. Конструкции /users/1/friends/3/items/4 будет неудобно использовать разработчикам клиентских приложений. Нужно избегать такую иерархию, нужно конкретно указывать что нам нужно, не перезагружать данными.

5. Соблюдайте версионирование API. Допустим: /api/v1/get_all_users и /api/v2/get_all_users. При выходе новой версии не всегда разработчики готовы переписать логику клиентских приложений, и для этого нам нужно разделять версии API

6. Чувствительные данные. Очень важный момент. Например, передача различных паролей в Query-параметрах запрещено, только в теле запроса.

7. Из 6 вытекает 7е правило: не логируйте персональные и прочие секретные данные. Было несколько случаев, когда из-за логирования параметров утекали данные пользователей.

8. Расширение ответов. Во-первых, не передавайте массивы в самом верхнем уровне ответа. JSON-ответ от сервера не должен быть массивом, только словарь (ключ-значение). Если мы будем возвращать список, в будущем нам будет неудобно расширить ответ сервера, добавив дополнительные параметры. А также иногда в API разработчики делают обязательные параметры, например помимо самих данных параметр success и error, чтобы клиентское приложение могло понять, что произошла ошибка, или наоборот, успешно выполнилось.

9. Работа с датой и временем. Есть два метода - использование Unix Timestamp (количество секунд прошедших с 1 января 1970 года). Это в какой-то степени более удобно для машины, но менее удобно для клиентского разработчика. И второй метод как раз делает формат даты и времени более понятным - это ISO 8601 (2025-04-05T12:00:00.100Z). Этот метод более удобный, т.к. мы понимаем дату и часовой пояс, точное время.

10. Бонусное правило, лично мое. Относится не только к REST API, но и в принципе к программированию. Пишите код так, как будто эта поэма, книга. Попробуйте сами поработать со своим API, будто вы его не писали. Разделение ответственности, единая точка отказа, Don't Repeat Yourself и даже Keep It Simple, Stupid. Все это конечно-же вариативно.

Полезные расширения для vsCode | просмотр JSON в виде дерева | Json Tree editor

Всем привет, этим постом начинаю серию постов с полезными плагинами для vsCode

🚀 Наименование: Json Tree editor

✍️Описание: расширение VSCode для визуализации данных JSON в виде дерева, с возможность выбора, перемещения и сортировки.

🔗 Ссылка на плагин: https://marketplace.visualstudio.com/items?itemName=GregChamblin.vscode-json-editor

Extension id: GregChamblin.vscode-json-editor

➕Плюсы:

• Можно работать с большими файлами json

• Есть отдельная кнопка на панели задач

• При перетаскивании в дереве элементов, сам json также изменяется онлайн

➖Минусы:

• Не выявлено

🚀Делитесь своими плагинами в комментариях.

#vsCode #JSON

Подписывайтесь на меня в телеграмм, там ещё много интересных плагинов @sa_chulan

[RFC] Открытый формат обмена данными об условиях кешбэка COIN

Многие банки и финансовые организации предлагают своим клиентам программы лояльности и/или кешбэк, тем самым повышая интерес к своим банковским/финансовым продуктам и поощряя клиентов за совершение покупок/оплату услуг. К сожалению нет определённого стандарта представления подробной информации об условиях, которые необходимо выполнить для получения вознаграждения/кешбэка (например, количество или общая сумма покупок или определение принадлежности торговой точки к той или иной категории (например, фастфуд или рестораны)).

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

Предлагаемое название для подобного формата "COIN" (Cashback (details) Open Interchange - открытый обмен данными о кешбэке).

В качестве формата хранения данных предлагается JSON. Прототип формата опубликован в репозитории.

Демо-сервис базовых возможностей использования формата COIN Кашевар-онлайн

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

Основные темы вебинаров:

• Защита веб-приложений (WAF)

• Защита интеграций между сервисами (API Security)

• Тренды развития рынка защиты веба

• Безопасная разработка

Для кого:

CISO

ИБ-специалисты

ИТ-специалисты

DevOps

Приготовьтесь к морю полезной информации, лучшим практикам и встрече с ведущими экспертами отрасли. Мы расставим все точки над «и».

Вы можете зарегистрироваться как на всю сессию сразу, так и на любой отдельный вебинар.

 Ссылка на регистрацию 

До встречи!

Генерация команд для создания сервера

Теперь при заказе конфига можно тут же сгенерировать команду для инструмента автоматизации, — Terraform, cURL или twc-cli. Вот краткий обзор каждого из них:

• Terraform. Помогает быстро разворачивать серверы, сети и управляемые сервисы в облаке.

• сURL. Утилита для управления ресурсами в облаке через API с помощью HTTP-запросов.

• twc-cli. Через терминал создает виртуалки, настраивает сети, кластеры и базы данных.

Чтобы сгенерировать команду, просто нажмите на кнопку рядом с «Заказать» → выберите один из способов автоматизации → скопируйте и вставьте команду в терминал или в файл.

Новая фича пока доступна только для виртуалок, но скоро раскатаем и на остальные облачные сервисы.

Автоматизировать управление сервером →

Как мы сокращали количество запросов по фичам в API

Контекст: я отвечаю за разработку конструктора Telegram-приложений. Начинались мы как конструктор кликеров (еще до хомяка). Со временем эволюционировали в конструктор курсов, сообществ, визиток, мероприятий и любых других приложений

Одна из основных сущностей в коде — это BotUser. То есть пользователь, который появился в приложении (зашёл хотя бы раз), имеет имя и Telegram ID

За ~полгода проекта у нас добавилось много фич, привязанных к пользователю. Практически все сопоставляются 1 к 1 по ключу User ID. Например, квизы, бонусные дни, купленные страницы, купленный карточки апгрейдов, тариф и т.д.

Раньше для каждой новой фичи мы добавляли новый запрос в API с фронтенда. И вот мы заметили, что на каждый заход пользователя стало уходить >10 запросов в API ⚠️.

Примерно вот так:

GET /users/user
// Response
{
  "tgUsername": ...,
  "tgId": ...,
  ...
}

GET /users/features/quizzes/completed
// Response
{
  "completedQuizzes": ...,
}
   
GET /users/features/pages/bought
// Response
{
  "boughtPages": ...,
}
   
GET /users/features/rates/rate
// Response
{
  "userRate": ...,
}

При этом, на каждый запрос мы проверяли авторизацию. В Telegram это делается с помощью хеша от Telegram + проверка подписи токеном бота

Следовательно, на каждый запрос мы делали JOIN пользователя, брали бота (сущность Bot) из кэша и мэтчили подпись (+ логгировали). Это лишняя нагрузка

Сейчас подсобрали все фичи в один запрос. Теперь, на каждый заход пользователя получается только один GET /app/account/data, который возвращает данные пользователя вместе с данными фичей:

GET /app/account/data

// Response
{
  ...
  "user": ...,
  "completedQuizzes": ...,
  "boughtPages": ...,
  "currentRate": ...,
  ...
}

За одно перепроверили, что:

• не подгружаем связанные сущности, где не нужно (one-to-one, one-to-many);

• если подгружаем сущности, всегда делаем это одним JOIN'ом (а не бегаем по 2-3 раза в БД, как любит делать Hibernate);

• берём общие часто запрашиваемые данные из кэшей.

Это позволило снизить нагрузку на сервер и БД. К посту прикрепляю график загрузки части наших серверов по CPU до и после оптимизации.

---

Если вам понравился пост или оказался полезным, поставьте, пожалуйста лайк ❤️. Это мотивирует делиться опытом из разработки. И, как полагается, у меня есть Telegram-канал, в котором я рассказываю про разработку, развитие SaaS-сервисов и управление IT проектами.

Коллеги, добрый день!

Наша линейка продуктов ПроAPI, основанная на собственной концепции к управлению и защите API, уже успела себя хорошо зарекомендовать. Однако задача ИБ-специалистов – постоянно быть на шаг впереди злоумышленников. Сегодня у нас есть идеи, как усилить безопасность и противостоять новым вызовам, мы хотели бы узнать ваше мнение относительно их.

По ссылке ниже мы предлагаем пройти небольшой опрос, который займет не более 10 минут.
https://t.me/wmx_xdrbot

Мы благодарны каждому, кто найдет время ответить на наши вопросы.
В конце анкеты обязательно укажите, как с вами связаться, чтобы мы смогли отправить небольшой подарок.

Joomla Web Services Collection For Postman

Разработчикам мобильных и WEB-приложений (и не только) весьма и весьма пригодится готовая коллекция для Postman. В коллекцию добавлены endpoint для REST API Joomla, с параметрами и примерами запросов.

Коллекция составлена трудами французского Joomla-разработчика Alexandre J-S William ELISÉ.

Смотреть коллекцию

Чат русскоязычного Joomla-сообщества

Добавляем подписку с Telegram Stars в свой апп

Я очень радовался 14.08.2024 из‑за выхода очередного релиза Телеграм, в котором они анонсировали подписки за звезды, потому что это сильно облегчало мое взаимодействие с клиентами: они один раз подписываются и далее не имеют проблем с повторными платежами, вместо этого звезды тихонько списываются у них с счетов. В этом посте я расскажу, как прикрутил подписку в звездах к своей Telegram Mini App (TMA).

Вот как выглядит глазами клиентов списание звезд в пользу вашей аппы. Заметьте, никаких предупреждающих писем, как у Stripe, например.

Свои подписки можно посмотреть у себя в профиле. Это выглядит так:

https://storage.googleapis.com/memes-repo/tutorial/100000998111.png

Отменить подписку можно, если вы зайдете в ее детали.

https://storage.googleapis.com/memes-repo/tutorial/1000009980.png

Теперь, когда вы представляете все визуально, то опишу последовательность вызовов, которые вы должны выполнить.

1. Создать счет на подписку.

2. Подтвердить оплату.

3. Принять первое и последующие сообщения об оплате.

### Создание счета

Для создания счета вызываем метод createInvoiceLink.

    def create_invoice(admin_chat_id: str, 
                       channel_id: str, 
                       title: str, 
                       description: str,
                       tariff_id: int, 
                       tariff_price: int,
                       ) -> dict:

        data = {
            "chat_id": admin_chat_id,
            "title": title,
            "description": description,
            "payload": json.dumps({"t": tariff_id}), 
            "provider_token": "",  # Empty
            "currency": "XTR", # required
            "prices": [{'amount': tariff_price, 'label': title}],
            "subscription_period": 2592000,
        }

        r = requests.post(f"{TG_API_URL}{TG_OP_SEND_INVOICE}", json=data)

Вещи, на которые обращаем внимание:

1. provider_token пустая строка

2. currency обязательно строка XTR

3. subscription_period обязательно 2 592 000

4. prices содержит только один элемент

### Подтверждение оплаты

Для получения подтверждения оплаты счета вам нужно добавить в ваш webhook (allowed_updates) подписку на pre_checkout_query. После этого вы начнете получать update c данным полем и структурой.

Когда вы получаете такой апдейт, вам нужно отреагировать на него в течение 10 секунд: принимаете или отклоняете (например, если этот счет уже был оплачен и другие краевые условия).

Данная структура также позволяет вам понять, что было оплачено в рамках счета, путем чтения поля payload (которое было записано при создании счета).

        pre_checkout_data: PreCheckoutData = {
            "id": packet["pre_checkout_query"]["id"],
            "currency": packet["pre_checkout_query"]["currency"],
            "total_amount": packet["pre_checkout_query"]["total_amount"],
            "invoice_payload": json.loads(packet["pre_checkout_query"]["invoice_payload"])
        }

Для подтверждения или отклонения оплаты счета используйте метод answerPreCheckoutQuery.

### Принять сообщения об оплате

На мое удивление сообщение об оплате встроено в существующий объект Message, так что не нужно дополнительно подписываться на новые источники данных. Вместо этого, мы просматриваем все message в поисках поля successful_payment или refunded_payment и записываем в статистику (для возможного возврата в том числе).

Обратите внимание! В структуре SuccessfulPayment есть параметр is_first_recurring, и я думал, что он True для первого платежа подписки и False для последующих, но! в последующих его просто нет (это допустимо, так как это необязательный параметр).

На этом все, как только вы начали получать successful_payment, вам не нужно больше делать ничего, чтобы клиент продлил подписку.

P.S. Вы всегда можете обновлять срок подписки при получении данного сообщения, читая поле subscription_expiration_date. Если successful_payment перестал приходить, то и подписка не обновится.

Ваш Дима из TG Defender, защита вашего Telegram канала от наплыва ботов на стиле.

Привет,Хабровчане ! Неожиданно решился на создание этой публикации – пусть она окажется полезной для кого-то из вас. Представьте ситуацию: рабочий день позади, включаем компьютер, запускаем музыкальное сопровождение и... прямо в кресле дивана нас уже сморит Морфей. Пробуждение же наполняет осознанием неразрешимой дилеммы – выключить ПК или переключить трек? Особенно когда репертуар оставляет желать лучшего!

Вот и приходится преодолевать себя, чтобы добраться до компьютера.

Так вот, в качестве решения этой проблемы разрабатываю приложение для Android с небольшим сервером на PC (начало только под Windows).

Основной фишкой станет регулировка яркости экранов, удаленное отключение ПК, переключение треков в плеере.

Телефонное приложение будет максимально чистым: без рекламы, подписок или дополнительных платежей.

Я – инженер(технарь), а не профессиональный программист, так что обещаю уделять больше внимания техническим моментам .

Все будет сделано в меру моих умений и возможностей. Благодарен за внимание! По мере продвижения работы буду дополнять этот пост новыми деталями.

А какого функционала не хватает вам ?

Сделал ещё несколько дэмок . 2 приложения на kivymd (python3) связь с сервером http запросами ,но вес приложения уменьшить не удалось . Попробовал на flutter спасибо Гуглу ,ии и другу разработчику ,связь. с сервером с помощью протокола mqtt.

$hyoo_lingua - удобный интерфейс перевода текстов.

В отличие от оригинального google translate, $hyoo_lingua не пытается транслитерировать английский текст при вводе в русское поле. В отличие от yandex translate, он не меняет языки сам как попало. В $hyoo_lingua ваш родной язык всегда слева, а чужой - справа, что очень удобно. Особенно, когда переводишь текст в обе стороны, чтобы убедиться в корректности перевода.

Ну и в отличие от обоих он не пытается переводить на лету текст в процессе ввода, вызывая мельтешение, изменение размера текста и исчерпание лимитов перевода, а ждёт сабмита (поддерживается и ctrl+enter).

Раньше он юзал нейронки с huggingface.co, но качество перевода было низким, а потом там закрутили гайки и всё сломалось.

Теперь используется гугловый движок через балансировку по шести бесплатным API с rapidapi.com, что даёт суммарный лимит в 10К переводов в месяц.

Кому не лень зарегаться - пришлите мне ключик, и подключите к нему бесплатные планы перечисленных тут апишек, чтобы кратно увеличить лимиты.

Программно же, в экосистеме MAM сейчас доступны следующие модули:

$mol_lang_iso639 - словарь всех 2-буквенных кодов языков и их названия на английском.

$mol_locale_select - компонент выбора языка.

$hyoo_lingua_translate( lang, text ) - перевод любого текста на заданный язык, используя веб-сервисы перевода.

Последней апишкой лучше не злоупотреблять, ибо лимиты у сервисов не резиновые.

Следите за остальными новостями из нашей экосистемы на канале @mol_news.

Теперь всем API-токенам можно ограничивать права. На уровне всех проектов сразу, или каких-то конкретных.

Можно выдавать права только на просмотр, на полное управление или полностью закрывать доступ к сервисам.

Это доступно как администраторам, так и доп пользователям — с учетом их собственных прав. При этом админ будет видеть, кто выпустил конкретный токен. А при блокировке доп пользователя автоматически удалятся и все выпущенные им токены.

Выпустить токен с ограничениями → 

Как в нативе: эти Web API поднимут ваше веб-приложение в стратосферу

Салют, на связи Clevertec. Сейчас наша команда разрабатывает веб-версию банкинга с использованием React. С помощью Web API даем пользователям фичи, которые они привыкли получать в нативных приложениях. Отрываем от сердца список решений 😉

- Web Share API – для обмена ссылками, текстом и файлами с другими приложениями на устройстве. К примеру, удобно отправить чек об оплате в мессенджере, не покидая банковское приложение. 

- Contact Picker API позволяет делиться контактами из своего списка. Можно использовать для перевода по номеру телефона. Не нужно вводить цифры вручную – поле автоматически заполнится контактом из телефонной книги. 

- Media Capture and Streams API в нашем случае позволяет отсканировать QR-код с помощью камеры устройства. Нажимаешь на “Сканировать QR” – открывается окно с камерой, она считывает код и переводит пользователя в дерево платежей.

- Web OTP API открывает возможность автоматически вставлять код из смс. Например, для подтверждения оплаты на телефон приходит сообщение. Внизу экрана появляется модальное окно с подтверждением вставки. И после нажатия на “Разрешить” код отображается в поле ввода.

Подробнее про этот опыт использования Web API мы рассказали в отдельной статье. Что вы думаете о Web API, какие используете? Расскажите в комментариях, будем взаимно полезны друг другу.  

Как в Авито устроено API-тестирование на Go?

В этом видео Глеб Дмитриев, инженер из команды Marketplace, рассказывает о проблемах, с которыми мы сталкивались на этапе выбора фреймворка для тестирования, и показывает, как работает наш собственный фреймворк на основе Testify.

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

Ранее Александр Трифанов, техлид Авито, рассказал о нашем подходе к сканированию данных в API.

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

В прошлом посте мы рассказали о нашем ПО Capsule для считывания, анализа и записи физиологических сигналов мозга и тела. Сегодня — про особенности интерфейса и API Neiry, которые нас радуют больше всего.

Capsule ориентирован на широкий круг пользователей. Научные коллективы могут использовать сырые потоковые или записанные мультимодальные данные для исследований. Те, кто не обладает глубокими знаниями в нейрофизиологии и смежных областях, запросто интегрируют готовые метрики на основе ЭЭГ и ФПГ в продукты. 

Мы храним необработанные мультимодальные данные в формате HDF5. С готовыми метриками можно работать в понятном для продукта виде. Когнитивная нагрузка со шкалой от 0 до 100 — пожалуйста, уровень усталости или расслабления в виде численного значения — запросто.

Нужно проверить гипотезу или разработать алгоритм «с нуля»? Потоковые сырые данные до фильтрации вам в помощь! Не хотите возиться с фильтрацией сигнала? Нет проблем, вот те же данные напрямую с АЦП, но после применения валидированных фильтров.

На устройстве небольшое количество электродов для снятия ЭЭГ, но мы постарались разместить их максимально разумно: два в затылочной области, два в височных, а референтный электрод и датчик ФПГ — на лбу.

Подробности расскажем и покажем на хакатоне BCI Hack Moscow 20–22 сентября. С помощью Neiry Headband Pro и API Neiry соберем игру на Unity, будем управлять устройствами умного дома, техникой и устроим брейн-ралли! Возможно даже покажем «Нейробуханку». Приходите, будет интересно.

Привет! На связи команда Neiry Tech, мы занимаемся разработкой BCI-устройств и алгоритмов для использования с ними. Расскажем про ПО Capsule, считывающее и записывающее мозговую активность, и другие физиологические сигналы пользователя. И Capsule API — он помогает нам строить на основе классифицированных метрик и индексов итоговые приложения).

По сути Capsule — библиотека для десктопных и мобильных платформ с собственным графическим интерфейсом. Для быстродействия написали её на C++. Для Capsule API выбрали C.

Для вывода в API на разных платформах иногда пишем нативный код на Android или iOS, ну и обертку на C, чтобы API мог использовать широкий спектр разработчиков — за родным ноутом и в лаборатории.

Физиологические данные — сложные сигналы с высоким уровнем шума. Для их интерпретации нужно хорошо владеть методами цифровой обработки сигналов, погрузиться в предметную область, и как минимум понимать, чем фильтр Чебышева отличается от фильтра Баттерворта.

Головной боли добавляют особенности различных платформ — с плавающими задержками протокола BLE, или с реализацией вроде бы базовых вещей. Мы как-то обнаружили, что библиотека, занимающаяся быстрым преобразованием Фурье, нагружала новенькие Apple Silicon на 30%.

Сейчас Capsule и API позволяют работать с данными ЭЭГ и ФПГ на высоком для не лабораторного устройства уровне. Смотрим, радуемся и гордимся.

Хотите поработать с этими данными и нашим API? Присоединяйтесь к хакатону BCI Hack Moscow, регистрация до 15 сентября.

Банкам не хватает просмотрового API

У меня несколько карт в нескольких банках. И мне очень не хватает возможности вывести все балансы всех карт в своем боте и сделать механизм оповещений о приближении баланса к пороговому.

Я каждый месяц выбираю категории кешбека и переключаю карты в приложениях. Например, вкусвилл — в этом месяце он у меня на ВТБ (категория супермаркеты). Средний заказ в ВВ — 3000 рублей и важно чтобы на карте было не меньше, потому что жена заказывает без предупреждения:)

На самих картах держать большие суммы нелогично в плане безопасности и по причине высоких ставок на накопительных счетах. Поэтому на картах держится X*2, где X — средние затраты по карте за день.

Смотреть за это глазами очень неудобно и у меня глаза ленивые, забывчивые и вообще мне доверять что-то помнить нельзя. Поэтому у нас с женой частое сообщение — "Антон, пополни карту для ВВ".

Очень жду, когда у банков будет просмотровый API, чтобы я мог подтягивать баланс по картам и счетам для отслеживания и сведения балансов. Понимаю, что это может противоречить политикам безопасности, но было бы дико удобно и мне нужен только "режим просмотра".

В комментах к посту в моем тг-канале кинули ссылку на новость от ЦБ, что 2026 у крупных банков должно будет быть API, а потом у всех МФО. Жду этого, возможно, даже больше чем полностью электронные документы для езды за рулем (права, доки на авто).

Всем привет!

Я уже писал о пользе стандартизации на примере формата данных для сохранения информации о сборке - cyclonedx. А недавно в посте про работу с исключениями упоминал библиотечку для возврата ошибок в API - jdoctor.

Так вот - стандартизация добралась и сюда)

Во-первых, как выяснилось - уже с 2016 года есть стандарт "Problem Details for HTTP APIs"
Во-вторых - в Spring Boot 3, т.е. с 2021 года, появилась его имплементация. Вот неплохое описание у baeldung
Если вкратце - ответ при ошибке будет иметь стандартизированный вид похожий на такой:
{
"type": "about:blank",
"title": "Bad Request",
"status": 400,
"detail": "Invalid request content",
"instance": "/sales/calculate"
}

Библиотеки, решающие подобную задачу в Java, уже были:

1. уже упомянутый jdoctor

2. error-handling-spring-boot-starter

   Но думаю, что именно данное решение - от Spring, да еще по стандарту - имеет шансы популяризовать данную практику.

Что еще хочется отметить:

1. стандартизация рулит) Каждый поставщик API разрабатывает формат для ответа при ошибке, каждый потребитель - специфический код для его обработки. А при этом понятно, что формат информации об ошибке мало зависит от бизнес-процесса

2. еще в 2018 году в Сбере формат ответа для REST был стандартизирован. Но, увы, формат отличается от RFC, а область применения ограничена взаимодействием с фронтом.

МТС представила платформу для бесшовной интеграции сервисов. Это собственная разработка компании — Интеграционная платформа (Integration Platform), которая позволяет бесшовно интегрировать сервисы в экосистему и обеспечивать их взаимодействие друг с другом.

На первом этапе платформа объединяет все API экосистемы в единый стек и позволят строить сложные интеграционные сценарии запуска сервисов, в том числе без привлечения разработчиков, через citizen developers — специалистов, которые создают сложные IT‑продукты, не имея глубинных знаний в области программирования.

Проект Integration Platform поддерживает широкий спектр индустриальных протоколов и стандартов, использует встроенные инструменты Low/No‑code и технологии искусственного интеллекта.

В ближайшее время платформой будет доступна внешним клиентам МТС, сфокусированным на модернизации ИТ‑ландшафта. Потенциальный экономический эффект от внедрения оценивается МТС в миллиарды рублей.

«Раньше создание новых продуктов требовало разработки новых API, команды искали актуальную документацию на существующие API, решения дублировались, подписание требовало согласований и обсуждений, был необходим единый реестр c полной документацией и понятным UX для подключения и публикации. Интеграционная платформа решила эту задачу. Это разработка МТС превосходит зарубежные аналоги по надежности, производительности и масштабируемости», — пояснил первый вице‑президент по технологиям МТС Павел Воронин.