Проектирование API *

В этом посте я расскажу, почему для доставки push-уведомлений в клиентское приложение была выбрана технология Server-Sent Events, и главное, как реализовать масштабируемый SSE сервис на Java + Spring Boot + Webflux, который подойдет для использования не только в небольших проектах, но и в крупных организациях с большим количеством пользователей. Естественно, без подготовки дополнительной инфраструктуры не обойдется.

Если ваш Битрикс тормозит, а Laravel кажется из другой вселенной — эта статья для вас.

На связи Алиса — тимлид в e-commerce агентстве KISLOROD. Мы ежедневно имеем дело с большими каталогами, сложной коммерцией и 1С, которая дышит в затылок. И однажды мы решили сделать невозможное: подружить Битрикс с Laravel. Так, чтобы Битрикс остался каноном и привычной админкой, а Laravel стал помощником — взял на себя API, тяжёлую бизнес-логику и все, что тормозит. Без форка ядра, слез SEO-шника и без утечек в 1С. Да, это реально.

Предупреждение: не сомневаюсь, что наверняка кто-то, прочитав данную статью, возжелает закидать меня тапками, но это его право, я не претендую на истину.

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

В наше время каждый слышал про Web-API и у многих это ассоциируется с REST. Однако этот многострадальный REST всегда какой-то не такой, с ним все время что-то не так.

Разработчики часто спорят и упрекают друг друга, что твой REST недостаточно REST-овый. Это стало чем-то вроде культа или даже религии. Я не планирую рассказывать о том, как правильно готовить REST, но весь материал именно вокруг этого многострадального RESTа.

Fast Healthcare Interoperability Resources (FHIR) - это прокотол для обмена медицинскими данными. Стандарт очень объемный, одних только ресурсов более полутора сотен, и цель данной статьи - дать стартовую точку для его изучения.

Это первый из запланированной серии постов посвященных FHIR технологиям, далее планирую добавить статьи с шагами регистрации и подключения к EPIC EHR, загрузки FHIR данных, их использования для формирования карты пациента и особенностями использования FHIR данных в AI чат-ботах.

Вчера вечером в Сан-Франциско прошла конференция DevDay 2025, на которой OpenAI представила масштабное обновление своей экосистемы. Компания заметно сместила фокус с потребительских продуктов на создание надёжной и масштабируемой платформы для разработчиков и корпоративного сегмента. Под руководством CEO Сэма Альтмана и при участии легендарного дизайнера Джони Айва мероприятие продемонстрировало новое видение ChatGPT как центральный хаб для взаимодействия с приложениями, данными и автоматизацией.

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

Команда AI for Devs подготовила перевод статьи о новом API /v1/responses от OpenAI, который объединяет простоту Chat Completions и мощь Assistants, и при этом сохраняет состояние рассуждений, мультимодальность и встроенные инструменты. Это шаг к агентам будущего — и, похоже, к новому стандарту работы с моделями OpenAI.

Современные системы состоят из множества различных сервисов и одной из основных задач является обеспечение обмена данными между компонентами системы. Для обеспечения этой функциональности используются шины данных (Enterprise Service Bus, ESB), интегрирующие различные приложения и системы в единую информационную среду. Она выступает в роли «посредника», минимизируя прямые связи между отдельными системами и обеспечивая гибкость взаимодействия. Таким образом, основная цель внедрения ESB — оптимизировать и унифицировать взаимодействие внутри информационного ландшафта предприятия.

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

Почти наверняка вы бывали в ситуациях, когда всё выпустили в прод, а сервер нагрузку не тянет. Или бизнес давит сроками, а времени на идеальные решения нет. Приходится подставлять костыли и ставить быстрые заплатки. Вопрос в том, могут ли они стать надежным решением? И какие компромиссы придется принять — об этом и поговорим.

А точнее: об оптимизации REST API в бою: как снизить количество запросов без потери данных, где проводить расчеты (и чем это грозит), зачем стандартизировать ответы, как кешировать с умом и почему health-check — это не просто «жив/мертв».

История о том, как очередная «быстрая костыль-интеграция» на коленке неожиданно превратилась в почти полноценную Order Management System (OMS) с элементами event-driven архитектуры. Всё это — без предварительного проектирования и без единой строчки кода на Java/Scala/Python (хотя тут немного лукавства, так как пару скриптов на Groovy все-таки имеется), на чистом Apache NiFi и SQLite.

Девизом этого проекта мог бы стать слоган: «Мы не ищем лёгких путей, мы ищем работающие решения». Я инженер в одной ритейл компании, который любит решать задачи, и сегодня расскажу, как закрыл боль бизнеса малой кровью, используя не совсем типичный для веб-сервисов инструмент.

Вот здесь можно посмотреть исходники

Привет, Хабр! Я старший системный аналитик, эксперт онлайн-школы по системному анализу Ольги Пономарёвой. Материал основан на реальных кейсах из практики: мы в школе System Analyst не просто рассказываем теорию, а делимся тем, что действительно работает на проектах.

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

В этой статье я расскажу, как правильно выявлять и формулировать НФТ.

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

Привет, Хабр! Каждый раз, создавая новый эндпоинт, я ловил себя на мысли: «А как назвать маршрут?». Казалось, что где-то есть законы и правила, которые помогают создавать API последовательно. Со временем я наткнулся на диаграммы по проектированию, прочитал книгу JJ Geewax — API Design Patterns (Джей‑Джей Гивакс), изучил рекомендации от крупных компаний и понял важную мысль: проектирование API — это такая же область знаний со своими принципами и стандартами.

Однако возникает проблема: стандарты есть, но они разные. Многие из них красивы на бумаге, но непонятно, как их применить в обычном CRUD‑приложении без сложной бизнес‑логики.

Цель статьи — дать компактную шпаргалку по проектированию API для простых CRUD‑сервисов и показать ход мыслей, который позволяет проектировать последовательно и осмысленно.

Есть за мной такой грешок: если какая-то проблема мне долго досаждает, я в конце концов пишу библиотеку, которая её решает. На сей раз такая история возникла с кодом для валидации CLI.

Смотрите, я немало времени уделяю чтению кода, который написали другие люди. Это код опенсорсных проектов, всякий материал по работе, а также код из случайных репозиториев с GitHub, на которые, бывает, наткнёшься в два часа ночи. Причём, я то и дело замечаю одну и ту же проблему: в любом инструменте CLI найдётся одинаковый уродливый валидационный код, запрятанный поглубже. Знаете, в таком роде:

Создавайте приложения так, чтобы они могли работать без пользовательского интерфейса или базы данных. Это позволит запускать автоматизированные регрессионные тесты, продолжать работу при недоступности базы данных, а также связывать приложения друг с другом без какого-либо участия пользователя.

Делимся опытом создания робота-диспетчера на low-code платформе n8n для обработки большого потока заказов. В статье рассказываем, как использовали Redis для очередей и динамической конфигурации, показываем реальные workflow и код, а также делимся, как боролись с утечками памяти и гонкой состояний. Будет полезно разработчикам, аналитикам и тимлидам, которые смотрят в сторону low-code для решения реальных бизнес-задач.

Команда Go for Devs подготовила перевод статьи о новом экспериментальном API для работы с JSON в Go. Спустя почти 15 лет после появления encoding/json в стандартной библиотеке разработчики столкнулись с его ограничениями. В версии Go 1.25 появился экспериментальный encoding/json/v2 — он решает старые проблемы, добавляет потоковую обработку и повышает производительность.

Многие частные инвесторы ведут свои портфели в Excel: это удобно, бесплатно и всё — на вашем компьютере. Но у Excel есть слабое место: он не умеет напрямую «разговаривать» с современными сайтами. Если нужно автоматически подтянуть котировку с конкретной страницы в интернете, встроенные веб‑функции часто не справляются: они не умеют обходить современные защиты.

В этой статье я покажу простой и надёжный способ заставить Excel получать котировки практически с любого сайта — на примере курса USD/RUB с investing.com. Идея не требует глубоких технических знаний: вместо того чтобы пытаться что-то делать со страницей в Excel, мы используем на своём компьютере небольшой скрипт‑посредник. Excel просто запрашивает у него одно число, а посредник уже «ходит» на сайт, берёт данные, при необходимости обрабатывает их и возвращает в понятном для Excel виде.

Приведённый Python‑скрипт (набор инструкций для этого «посредника») — это учебный пример: он предназначен исключительно для демонстрации принципа работы с API и веб‑технологиями. Я не призываю и не рекомендую использовать его для обхода правил каких‑либо сайтов.

Все исходные файлы проекта доступны в репозитории на GitHub.

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

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

Команда Go for Devs подготовила перевод статьи о том, как превратить SQL в полноценный API прямо в Go. Автор показывает, как можно безопасно принимать WHERE-условия в виде SQL-подзапросов, валидировать их и использовать для запросов к базе. Просто, элегантно и почти без лишнего кода.