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

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

В предыдущей части мы рассматривали способ получить мгновенные метрики по запросу. В этой части мы будем делать простой алертинг, то есть получение сообщения в боте, когда в системе начались сбои. А в следующей третьей части разберем еще случай сбора аналитики и получения онлайн графиков.

Привет, Хабр! На связи Антон, руководитель Архитектурного комитета компании SimbirSoft. Вместе с моими коллегами в прошлой статье мы рассказали про особенности применения подхода Design API First. Сегодня покажем, как реализуется этот подход на практике на примере сервиса аутентификации пользователей.

Есть и продолжение, 3 часть: Интеграция паттерна Design API First в конвейер разработки ПО: наш опыт

4 часть: Как генерировать модели интерфейсов на основе спецификации на стороне frontend-приложений

5 часть: Design API First. Кодогенерация Roslyn

Это глава 38 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Как мы уже отмечали в предыдущих главах, стандарты HTTP и URL, а также принципы REST, не предписывают определённой семантики значимым компонентам URL (в частности, частям path и парам ключ‑значение в query). Правила организации URL в HTTP API существуют только для читабельности кода и удобства разработчика. Что, впрочем, совершенно не означает, что они неважны: напротив, URL в HTTP API являются средством выразить уровни абстракции и области ответственности объектов. Правильный дизайн иерархии сущностей в API должен быть отражён в правильном дизайне номенклатуры URL.

NB: отсутствие строгих правил естественным образом привело к тому, что многие разработчики их просто придумали сами для себя. Некоторые наиболее распространённые стихийные практики, например, требование использовать в URL только существительные, в советах по разработке HTTP API в Интернете часто выдаются за стандарты или требования REST, которыми они не являются. Тем не менее, демонстративное игнорирование таких самопровозглашённых правил тоже не лучший подход для провайдера API, поскольку он увеличивает шансы быть неверно понятым.

Традиционно частям URL приписывается следующая семантика:

За окном 2023 год, а среди разработчиков только и разговоров, что про микросервисы да API First. Несмотря на то, что эти темы не новы, похоже, что их актуальность даже набирает обороты.

Про микросервисы уже много написано и теоретического и практического. Есть у этого подхода и свои евангелисты (Microservice Architecture) :) В целом это тема достаточно холиварная, особенно при крайних точках зрения. Сегодня мы ее отложим, но обязательно вернемся в контексте темы этой статьи. Конечно, это будет не менее обсуждаемая история, посвященная методологии API First и программным интерфейсам (прежде всего, web, но не только) при проектировании и разработке современных информационных систем :)

Меня зовут Антон, я руководитель Архитектурного комитета в компании SimbirSoft. Мы используем подход API First для проектов самой разной направленности, где есть несколько команд разработки (как минимум Backend и Frontend), а также при высокой неопределенности на этапе реализации (быстроменяющиеся требования и цели, параллельные процессы проектирования и реализации, высокие запросы к TTM и так далее).

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

Этот материал открывает цикл статей, посвященных практическому внедрению методологии API First в разработку наших команд. Если быть точным, то мы отдаем предпочтение «младшему брату» API First, практикующему  проектирование (design), — известному как Design API First. Чтобы избежать путаницы, далее термин «API First» будет обозначать подход к разработке ПО, а термины «Design API First» и «Design First» – проектирование ПО в рамках подхода API First.

2 часть: Как мы внедряли Design API First. Показываем на примере сервиса аутентификации

3 часть: Интеграция паттерна Design API First в конвейер разработки ПО: наш опыт

4 часть: Как генерировать модели интерфейсов на основе спецификации на стороне frontend-приложений

5 часть: Design API First. Кодогенерация Roslyn

Всем привет. Эта статья будет полезна тем, кто столкнулся с проблемой проверок доверенностей при работе с электронным документооборотом через СБИС и Диадок.  Речь идет не о МЧД (машиночитаемой доверенности), а о проверке обычных бумажных доверок.

Так же возможно кому то просто будет полезно почерпнуть принципы работы через API.

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

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

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

Это глава 37 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

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

Эти принципы мы должны применить к протоколу HTTP, соблюдая дух и букву стандарта: URL операции должен идентифицировать ресурс, к которому применяется действие, и быть ключом кэширования для GET и ключом идемпотентности — для PUT и DELETE; HTTP‑глаголы должны использоваться в соответствии с их семантикой; свойства операции (безопасность, кэшируемость, идемпотентность, а также симметрия GET / PUT / DELETE‑методов), заголовки запросов и ответов, статус‑коды ответов должны соответствовать спецификации.

Привет! Меня зовут Анастасия Иванова, я работаю в МТТ (входит в экосистему МТС) техническим писателем МТС Exolve. В этой статье я расскажу, какие есть варианты для замены привычных коробочных решений и где точно нужно задуматься о переходе на API.

В данной статье разберем, как писать gRPC автотесты с использованием языка Go, также сделаем Allure отчет.

Привет, Хабр! Сегодня мы разберёмся, как добавлять кастомные плагины в Gravitee.io

Gravitee.io - open source продукт-шлюз с витриной API. Эта статья рассчитана на тех, кто уже знаком с системой. Общая информация о продукте хорошо описана в статье: Что такое системы API Management.

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

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

Это главы 36 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

После трёх вступительных глав с прояснением основных терминов и понятий (такова, увы, цена популярности технологии) у читателя может возникнуть резонный вопрос — а почему вообще существует такая дихотомия: какие-то API полагаются на стандартную семантику HTTP, а какие-то полностью от неё отказываются в пользу новоизобретённых стандартов. Например, если мы посмотрим на формат ответа в JSON-RPC, то мы обнаружим, что он легко мог бы быть заменён на стандартные средства протокола HTTP. Вместо

Вопросы организации HTTP API — к большому сожалению, одни из самых «холиварных». Будучи одной из самых популярных и притом весьма непростых в понимании технологий (ввиду большого по объёму и фрагментированного на отдельные RFC стандарта), спецификация HTTP обречена быть плохо понятой и превратно истолкованной миллионами разработчиков и многими тысячами учебных пособий.

Как я писал библиотеку для Дневника МЭШ? Сколько проблем было? Как долго я хранил идею? Сколько времени понадобилось? Вы все узнаете в этой статье. Я постарался уместить кратко и понятно.

Привет, Хабр! В одной из прошлых своих статей я уже писал про API для работы с SMS-сообщениями от компании МТТ (входит в экосистему МТС). На этом можно было бы и остановиться, если бы не одно «но». Не так давно вышла в свет платформа МТС Exolve за авторством всё той же компании МТТ. Методы для работы с SMS у MTT Telecom API и MTC Exolve очень похожи, за исключением одного: чтобы «покрутить в руках» MTC Exolve, не нужно заключать договор.

Cегодня мы  «поймаем двух зайцев»: посмотрим, как работает GitHub Actions и научимся отправлять SMS с помощью МТС Exolve.

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

На связи Вячеслав Шмельцер, backend-разработчик, и Рамиль Алешкин (alewkinr), Product Owner Консоли управления #CloudMTS.

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

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

Загадка непрочитанных сообщений: Почему мы подписаны на телеграм-каналы, которые не читаем?

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

Обсуждаем влияние явлений, таких как FOMO и думскроллинг на нашу потребность в информации.

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

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

Я бы хотела поделится своим опытом и рассказать, как помогает автоматизация рутинных задач с использованием Javascript и Google Apps Script. Возможно, это поможет многим для экономии рабочего времени в дальнейшем отделу HR и менеджерам управления проектов.

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

Было принято решение самим брать данные из системы без использования платных сервисов. Для этого мы использовали расширение Google Apps Script.

Я являюсь junior разработчиком, данная статья для тех, кому будет полезной следующая информация:

Как записать массив данных в таблицу?

В интернете не было информации или хотя бы намека, как мы можем построчно записать данные в таблицу Google Sheets из массива используя Apps Script.