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

Каждый инвестор рано или поздно сталкивается с необходимостью ведения учёта своего портфеля, особенно если брокеров несколько. В первом приближении для этого подходит Excel: многим знаком, работает локально и почти всегда установлен на компьютере. Подходит для расчета доходности, учета дивидендов.

Однако механическая работа со временем утомляет, а возможности Excel для автоматизации онлайн получения котировок ограничены. Google Таблицы решают эту проблему: это изначально облачный инструмент. Чтобы получить актуальную цену акций, достаточно одной формулы.

В этой статье мы разберём, как Google Таблицы могут дать инвестору больше свободы. Я покажу на примерах, как с помощью встроенных инструментов и простых гугл скриптов (Google Apps Script) превратить таблицу в полноценную платформу для анализа и автоматизации вашего портфеля. А ещё разберем получение котировок в обоих инструментах.

Привет, Хабр!

Мы тут в свободное время пилим проект, который должен решить боль многих айтишников, — автоматизировать рутинный поиск работы. Идея выросла в Telegram-бота «Аврора» , который на "автопилоте" ищет вакансии на hh.ru и откликается на них.

Но чтобы "автопилот" был полезным, он должен быть надежным. Никому не нужен ассистент, который при первом же деплое новой версии или падении сервера забывает, что он делал, и какие вакансии уже отправил.

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

Под катом — наш подход к Graceful Shutdown, восстановлению сессий и немного про то, как LLM (в нашем случае Gemini) генерирует поисковые запросы.

В этом посте я расскажу, почему для доставки 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 по базам научных публикаций, стандартам, книгам, мессенджерам и социальным сетям.

Современные системы состоят из множества различных сервисов и одной из основных задач является обеспечение обмена данными между компонентами системы. Для обеспечения этой функциональности используются шины данных (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 найдётся одинаковый уродливый валидационный код, запрятанный поглубже. Знаете, в таком роде:

Именно в этой статье 2005 года был впервые представлен и описан паттерн гексагональной архитектуры (также известной как «порты и адаптеры»). Цель этого паттерна — строго изолировать ядро приложения, обеспечив его независимость от пользовательского интерфейса, баз данных или сторонних сервисов. Такой подход не только гарантирует тестируемость и гибкость системы, но и делает ее устойчивой к изменениям во внешнем окружении.

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

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

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

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

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

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

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

Основная часть работы современных разработчиков ПО¹ связана с API: публичными интерфейсами для общения с программой, например, API Twilio. Я потратил кучу времени на работу с API как их разработчик и пользователь. Я писал публичные API для сторонних разработчиков, приватные API для внутреннего использования (или для потребления одной страницей фронтенда), API REST и GraphQL и даже несетевые интерфейсы, например, для инструментов командной строки.

Думаю, большинство рекомендаций по проектированию API слишком уж уходит в тонкости. Разработчики отвлекаются на обсуждения того, что же такое «реальный» REST, правильно ли использовать HATEOAS и так далее. В этом посте я попытаюсь рассказать всё, что знаю о проектировании хороших API.