🏆 Лучшие практики проектирования API
В названиях путей к эндпоинтам используем имена, а не глаголы
В метода HTTP-запроса уже содержится глагол. Ставить глаголы в названиях путей к конечной точке API не добавит никакой ценной информации
✅
Соблюдаем единообразие интерфейсов (принцип REST №4)
✅
Если есть сущности, которые состоят из других сущностей, то нужно показать это в адресе ресурса. Это поможет понять структуру и связи между сущностями.
✅
Существует много кодов HTTP. Важно, чтобы HTTP-код был верным
✅ возвращать код 200, когда всё ОК и запрос отработал без ошибок
✅ “пятисотить” только в случае аварийной ситуации/багов/исключений на нашей стороне
✅ по коду HTTP понятно состояние запроса, например, 404 – не найдено
❌ возвращать код 200 с информацией об ошибке в body
❌ возвращать код 5xx, когда получена стандартная ошибка
❌ всегда возвращать коды 400 или 500 без использования разнообразия
Используем уместные HTTP-методы
GET – получение данных о ресурсах
POST – создание новых ресурсов
PUT – полное обновление существующих ресурсов
PATCH – обновление только определённых полей уже существующих ресурсов
DELETE – удаление ресурса
Используем пагинацию/оффсеты для массивных данных
Если у нас есть метод, который, например, возвращает список всех заказов, то не стоит вытягивать все данные за один раз. Вместо этого лучше добавить пагинацию или оффсет, чтобы извлекать часть данных и не создавать лишнюю нагрузку
Кэшируем данные для улучшения производительности
В некоторых случаях может быть полезно сохранять в быстрой памяти (например, в Redis) данные вместо того, чтобы каждый раз выполнять ряд сложных запросов к БД или внешним системам (см. наш пост про кэширование).
Применяем версионирование API
У нас должны быть различные версии API на тот случай, если мы вносим в них такие изменения, которые могут нарушить работу клиента. Так мы можем соблюсти требование обратной совместимости.
Например, есть метод публикации статьи, который уже на проде и используется несколькими потребителями. Необходимо добавить новый обязательный параметр в теле входящего запроса:
✅ Создать новую версию API метода
❌ Выкатить изменения сразу на
Ещё несколько рекомендаций
❌ Передавать токены аутентификации в URL или в body
✅ Передавать токены аутентификации в заголовках
✅ Использовать kebab-case для URL и camelCase для параметров
✅ Использовать даты в формате ISO 8601. Отображение дат в конкретном часовом поясе – задача клиента.
✅ Возвращать созданные ресурсы после POST. Это поможет клиенту, например, узнать сгенерированный ID и не делать лишних запросов
✅ Используйте PUT, если нужно заменить ресурс целиком. Используйте PATCH, если нужно изменить в ресурсе лишь часть данных.
📎 Статьи
1. Наилучшие практики создания REST API — Habr
2. RESTful web API design — Microsoft
3. Как проектировать веб-API: 7 самых важных вопросов — Babok School
4. Best Practices, которые стоит использовать при проектировании REST API — советы от ведущего системного аналитика
5. Как построить REST-like API в крупном проекте — опыт от ЮMoney
6. Рекомендации по REST API — примеры Habr
⏯ Видео
1. Проектирование API в терминах RESTful — доклад Алексея Романова на конференции Analyst Days EA #1
2. Паттерны проектирования API — доклад Андрея Буракова из VK Pay на конференции Analyst Days-12 (скачать .pptx)
3. Как аналитику спроектировать свой REST API — демо-занятие курса от OTUS
📚 Книги
1. Джей Гивакс. Паттерны проектирования API
2. Арно Лоре. Проектирование веб-API
3. Сергей Константинов. API
#api #интеграции #проектирование
В названиях путей к эндпоинтам используем имена, а не глаголы
В метода HTTP-запроса уже содержится глагол. Ставить глаголы в названиях путей к конечной точке API не добавит никакой ценной информации
✅
GET /v1/articles/{id}
❌ POST /v1/get-article/{id}
Коллекции называем существительными во множественном числеСоблюдаем единообразие интерфейсов (принцип REST №4)
✅
GET /v1/articles/{id}
❌ GET /v1/article/{id}
Иерархия сущностей должны отражаться в URLЕсли есть сущности, которые состоят из других сущностей, то нужно показать это в адресе ресурса. Это поможет понять структуру и связи между сущностями.
✅
GET /v1/articles/{id}/comments
❌ GET /v1/article-comments?article_id={id}
Используем подходящие коды ошибокСуществует много кодов HTTP. Важно, чтобы HTTP-код был верным
✅ возвращать код 200, когда всё ОК и запрос отработал без ошибок
✅ “пятисотить” только в случае аварийной ситуации/багов/исключений на нашей стороне
✅ по коду HTTP понятно состояние запроса, например, 404 – не найдено
❌ возвращать код 200 с информацией об ошибке в body
❌ возвращать код 5xx, когда получена стандартная ошибка
❌ всегда возвращать коды 400 или 500 без использования разнообразия
Используем уместные HTTP-методы
GET – получение данных о ресурсах
POST – создание новых ресурсов
PUT – полное обновление существующих ресурсов
PATCH – обновление только определённых полей уже существующих ресурсов
DELETE – удаление ресурса
Используем пагинацию/оффсеты для массивных данных
Если у нас есть метод, который, например, возвращает список всех заказов, то не стоит вытягивать все данные за один раз. Вместо этого лучше добавить пагинацию или оффсет, чтобы извлекать часть данных и не создавать лишнюю нагрузку
Кэшируем данные для улучшения производительности
В некоторых случаях может быть полезно сохранять в быстрой памяти (например, в Redis) данные вместо того, чтобы каждый раз выполнять ряд сложных запросов к БД или внешним системам (см. наш пост про кэширование).
Применяем версионирование API
У нас должны быть различные версии API на тот случай, если мы вносим в них такие изменения, которые могут нарушить работу клиента. Так мы можем соблюсти требование обратной совместимости.
Например, есть метод публикации статьи, который уже на проде и используется несколькими потребителями. Необходимо добавить новый обязательный параметр в теле входящего запроса:
✅ Создать новую версию API метода
POST /v2/articles и добавить новый параметр туда, а POST /v1/articles оставить без изменений❌ Выкатить изменения сразу на
POST /articles без всякого версионирования, чтобы потребителям жилось веселееЕщё несколько рекомендаций
❌ Передавать токены аутентификации в URL или в body
✅ Передавать токены аутентификации в заголовках
✅ Использовать kebab-case для URL и camelCase для параметров
✅ Использовать даты в формате ISO 8601. Отображение дат в конкретном часовом поясе – задача клиента.
✅ Возвращать созданные ресурсы после POST. Это поможет клиенту, например, узнать сгенерированный ID и не делать лишних запросов
✅ Используйте PUT, если нужно заменить ресурс целиком. Используйте PATCH, если нужно изменить в ресурсе лишь часть данных.
📎 Статьи
1. Наилучшие практики создания REST API — Habr
2. RESTful web API design — Microsoft
3. Как проектировать веб-API: 7 самых важных вопросов — Babok School
4. Best Practices, которые стоит использовать при проектировании REST API — советы от ведущего системного аналитика
5. Как построить REST-like API в крупном проекте — опыт от ЮMoney
6. Рекомендации по REST API — примеры Habr
⏯ Видео
1. Проектирование API в терминах RESTful — доклад Алексея Романова на конференции Analyst Days EA #1
2. Паттерны проектирования API — доклад Андрея Буракова из VK Pay на конференции Analyst Days-12 (скачать .pptx)
3. Как аналитику спроектировать свой REST API — демо-занятие курса от OTUS
📚 Книги
1. Джей Гивакс. Паттерны проектирования API
2. Арно Лоре. Проектирование веб-API
3. Сергей Константинов. API
#api #интеграции #проектирование
🔥19👍13❤3🤣2
Forwarded from Библиотека Системного Аналитика
Please open Telegram to view this post
VIEW IN TELEGRAM
GraphQL: основные понятия
GraphQL — это язык запросов и серверная среда для API с открытым исходным кодом. Он был специально создан как альтернатива REST API, чтобы избежать с одной стороны избыточности данных, а с другой их недостатка.
Главная фишка GraphQL: клиент может получить все нужные данные одним запросом к одному эндпоинту, даже если они будут располагаться в разных источниках. При этом структуру ответа определяет сам потребитель.
⚙️ Принцип работы
По сути GraphQL выполняет роль оркестратора – переадресовывает фрагменты запроса на разные сервисы. GraphQL умеет отправлять данные поверх HTTP-протокола, Websocket и SSH.
В GraphQL есть всего два вида запросов:
1. query – запросы на чтение данных (используется метод GET в HTTP)
2. mutation – запросы на изменение данных (используется метод POST в HTTP)
То есть, если рассматривать акроним CRUD, то query – это R, а mutation – это RUD.
Все запросы клиенты отправляют на одну конечную точку: GraphQL-сервер. Он представляет собой обычный HTTP-сервер, к которому присоединена GraphQL-схема. GraphQL-схема аналогична понятию “контракт” в REST API: схема определяет, какие операции клиент может выполнить в API и определяет, какие типы данных будут использоваться.
GraphQL имеет строгую типизацию. Типы бывают следующие:
▪️Объектные – сущности с вложенными полями и другими сущностями
▪️Скалярные – могут содержать только одно атомарное значение. К ним относятся:
▫️ Int (целочисленные) — 32-битное целое число со знаком;
▫️ Float — число двойной точности с плавающей точкой со знаком;
▫️ String — строка, закодированная в UTF-8;
▫️ Boolean (булевы) — логический тип (true или false).
Пример запроса GraphQL
➖ Сложность. Для небольших простых приложений настройка таких запросов может показаться слишком сложной и ненужной. В этой ситуации легко можно обойтись классическим REST-подходом
➖ Нет кеширования. GraphQL использует всего одну конечную точку, что не позволяет следовать спецификации HTTP-кеширования. Это очень важно, так как кеширование уменьшает объем трафика.
➖ GraphQL обычно возвращает статус 200 OK даже с ошибкой, но при использовании специальных клиентов эта проблема легко решается.
➖ Трудности обеспечения безопасности с учётом всех возможных вариантов запросов
💻 Применение GraphQL
1️⃣ GraphQL API хорошо подходит для приложений с большим количеством клиентов и/или источников данных, когда нужно реализовать единообразие в средствах выполнения запросов, уменьшить число конечных точек и снизить нагрузку на сеть.
2️⃣ GraphQL отлично подходит для баз с большим количеством записей, позволяя устранить избыточную выборку результатов и получать только нужные данные, чтобы повысить производительность приложения.
3️⃣ Когда нет четкого понимания, как клиент использует API, без необходимости заранее определять строгий контракт: можно постепенно создавать API на основе отзывов клиентов.
🌐 Официальная документация
📑 Статьи (теория)
1. Что такое GraphQL — статья от ListenIT + видео-версия
2. Подробности о GraphQL: что, как и почему — статья от RUVDS
3. The complete GraphQL Security Guide — про безопасность на EN
4. Начало работы с безопасностью GraphQL — про безопасность на RU
📝 Статьи (практика)
1. Проектируем GraphQL API в микросервисной архитектуре — опыт от Звука
2. Как и для чего мы два раза переезжали на GraphQL — опыт Яндекс.Афиши
3. GraphQL: от восторга до разочарования
4. Что не так с GraphQL — взгляд разработчика
5. Знакомство с GraphQL: примеры запросов к своей БД в облаке Hasura — туториал для аналитиков, если хотите потыкать ручками
⏯ Видео и вебинары
1. GraphQL — проектируем интеграцию систем — Анна Овзяк
2. А нужен ли нам GraphQL? — Павел Черторогов
3. Все о GraphQL за 30 минут — от разработчика
4. Про безопасность GraphQL
👐 Открытое API GraphQL
1. API GitHub — документация + попробовать онлайн
2. API Space X онлайн
#api #интеграции
GraphQL — это язык запросов и серверная среда для API с открытым исходным кодом. Он был специально создан как альтернатива REST API, чтобы избежать с одной стороны избыточности данных, а с другой их недостатка.
Главная фишка GraphQL: клиент может получить все нужные данные одним запросом к одному эндпоинту, даже если они будут располагаться в разных источниках. При этом структуру ответа определяет сам потребитель.
⚙️ Принцип работы
По сути GraphQL выполняет роль оркестратора – переадресовывает фрагменты запроса на разные сервисы. GraphQL умеет отправлять данные поверх HTTP-протокола, Websocket и SSH.
В GraphQL есть всего два вида запросов:
1. query – запросы на чтение данных (используется метод GET в HTTP)
2. mutation – запросы на изменение данных (используется метод POST в HTTP)
То есть, если рассматривать акроним CRUD, то query – это R, а mutation – это RUD.
Все запросы клиенты отправляют на одну конечную точку: GraphQL-сервер. Он представляет собой обычный HTTP-сервер, к которому присоединена GraphQL-схема. GraphQL-схема аналогична понятию “контракт” в REST API: схема определяет, какие операции клиент может выполнить в API и определяет, какие типы данных будут использоваться.
GraphQL имеет строгую типизацию. Типы бывают следующие:
▪️Объектные – сущности с вложенными полями и другими сущностями
▪️Скалярные – могут содержать только одно атомарное значение. К ним относятся:
▫️ Int (целочисленные) — 32-битное целое число со знаком;
▫️ Float — число двойной точности с плавающей точкой со знаком;
▫️ String — строка, закодированная в UTF-8;
▫️ Boolean (булевы) — логический тип (true или false).
Пример запроса GraphQL
query {
user(id: 123) {
name
email
age
}
}
Пример ответа{
"data": {
"user": {
"name": "John Doe",
"email": "johndoe@example.com",
"age": 30
}
}
}
🚧 Ограничения➖ Сложность. Для небольших простых приложений настройка таких запросов может показаться слишком сложной и ненужной. В этой ситуации легко можно обойтись классическим REST-подходом
➖ Нет кеширования. GraphQL использует всего одну конечную точку, что не позволяет следовать спецификации HTTP-кеширования. Это очень важно, так как кеширование уменьшает объем трафика.
➖ GraphQL обычно возвращает статус 200 OK даже с ошибкой, но при использовании специальных клиентов эта проблема легко решается.
➖ Трудности обеспечения безопасности с учётом всех возможных вариантов запросов
💻 Применение GraphQL
1️⃣ GraphQL API хорошо подходит для приложений с большим количеством клиентов и/или источников данных, когда нужно реализовать единообразие в средствах выполнения запросов, уменьшить число конечных точек и снизить нагрузку на сеть.
2️⃣ GraphQL отлично подходит для баз с большим количеством записей, позволяя устранить избыточную выборку результатов и получать только нужные данные, чтобы повысить производительность приложения.
3️⃣ Когда нет четкого понимания, как клиент использует API, без необходимости заранее определять строгий контракт: можно постепенно создавать API на основе отзывов клиентов.
🌐 Официальная документация
📑 Статьи (теория)
1. Что такое GraphQL — статья от ListenIT + видео-версия
2. Подробности о GraphQL: что, как и почему — статья от RUVDS
3. The complete GraphQL Security Guide — про безопасность на EN
4. Начало работы с безопасностью GraphQL — про безопасность на RU
📝 Статьи (практика)
1. Проектируем GraphQL API в микросервисной архитектуре — опыт от Звука
2. Как и для чего мы два раза переезжали на GraphQL — опыт Яндекс.Афиши
3. GraphQL: от восторга до разочарования
4. Что не так с GraphQL — взгляд разработчика
5. Знакомство с GraphQL: примеры запросов к своей БД в облаке Hasura — туториал для аналитиков, если хотите потыкать ручками
⏯ Видео и вебинары
1. GraphQL — проектируем интеграцию систем — Анна Овзяк
2. А нужен ли нам GraphQL? — Павел Черторогов
3. Все о GraphQL за 30 минут — от разработчика
4. Про безопасность GraphQL
👐 Открытое API GraphQL
1. API GitHub — документация + попробовать онлайн
2. API Space X онлайн
#api #интеграции
👍16🔥8❤3
🆚 GraphQL vs REST: сравнение по пунктам
И снова рубрика #сравнение.
Ранее мы писали главное о GraphQL и собрали материалы для изучения, а сегодня попробуем понять, может ли он заменить REST.
Все запросы идут через один эндпоинт
🔹 Если нужно собрать агрегированные данные из различных сервисов, в REST придётся делать несколько запросов к каждому сервису.
🔸 В GraphQL клиенты могут получать данные из нескольких сервисов одним запросом к одной конечной точке.
Получаем только то, что нам нужно
🔹 REST API часто возвращают либо слишком много, либо слишком мало данных. Клиенты обычно получают все доступные поля ресурса, даже если им требуется только часть данных. Такая избыточность вносит свою лепту в увеличении времени ответа. И наоборот, недостаточная выборка возникает, когда клиенту приходится делать несколько запросов к различным эндпоинтам, чтобы получить необходимые данные, что генеририт дополнительную нагрузку и увеличивает время ответа.
🔸 В GraphQL клиент может именно те данные, которые им нужны, указывая в запросах необходимые поля. Это позволяет избежать избыточной или недостаточной выборки данных, сокращая объем ненужной информации, передаваемой между клиентом и сервером.
Схема данных и типизация
🔹 Классический REST не даёт строгих определений по используемым типам и не определяет схему данных. Однако можно использовать, например, спецификацию OpenAPI.
🔸 GraphQL требует определения схемы, которая описывает все данные и их типы, а также способы доступа клиентов к этим данным или их изменения.
Сложнее версионирование API
🔹 В REST мы легко можем внедрить новую версию метода, не прекращая поддержку старой. Например, если для метода получения статей в блоге нужно добавить новый обязательный параметр в теле входящего запроса, то мы можем создать новую версию API метода
🔸 GraphQL не поддерживает версионирование по URL, так как у нас только одна точка входа. Однако версионирование можно организовать через создание новых query либо настроить специальные предупреждения для устаревших полей, возвращаемых клиенту.
Сложность кэширования запросов
🔹 Кэширование – это один из 6 принципов REST. В REST мы можем кэшировать запросы к эндпоинтам. Это позволяет снизить нагрузку на серверы и ускоряет получение ответа для клиента.
🔸 Хотя физически в GraphQL можно реализовать кэширование на уровне запросов, в реальности этим не занимаются, так как вариаций запросов может существовать бесчисленное множество. В одном запросе вы можете затребовать имя автора, а в следующем – не только имя автора, но и адрес его электронной почты. Именно для таких случаев вам понадобится более филигранный кэш на уровне полей, а реализовать его не так-то просто. Однако, большинство библиотек, построенных поверх GraphQL, предлагают такие механизмы кэширования прямо «из коробки».
Нет кодов состояний
🔹 REST позволяет возвращать любые доступные коды ответов HTTP, что позволяет клиенту понять результат запроса и среагировать на него.
🔸 GraphQL обычно возвращает статус 200 OK даже с ошибкой, но при использовании специальных клиентов эта проблема легко решается.
❓Что использовать в работе
Итак, REST API применяют, если:
➖ работают с небольшими программами, где нужно обрабатывать простые данные
➖ пользователи работают с ними одинаково
➖ нет требований к сложным запросам
GraphQL выбирают, когда:
➖ у серверного оборудования маленькая пропускная способность и нужно снизить количество ввода-вывода данных
➖ в одном адресе нужно объединить множество источников
➖ запросы пользователей различны, необходимо прорабатывать разные ответы
📎 Ссылки
1. REST API vs GraphQL: в чём между ними разница — МТС
2. В чем разница между GraphQL и REST? — Amazon
3. Сравнение REST и GraphQL
4. GraphQL vs REST: 4 Critical Differences
5. GraphQL vs REST - кто круче? — видео
#сравнение #api #интеграции
И снова рубрика #сравнение.
Ранее мы писали главное о GraphQL и собрали материалы для изучения, а сегодня попробуем понять, может ли он заменить REST.
Все запросы идут через один эндпоинт
🔹 Если нужно собрать агрегированные данные из различных сервисов, в REST придётся делать несколько запросов к каждому сервису.
🔸 В GraphQL клиенты могут получать данные из нескольких сервисов одним запросом к одной конечной точке.
Получаем только то, что нам нужно
🔹 REST API часто возвращают либо слишком много, либо слишком мало данных. Клиенты обычно получают все доступные поля ресурса, даже если им требуется только часть данных. Такая избыточность вносит свою лепту в увеличении времени ответа. И наоборот, недостаточная выборка возникает, когда клиенту приходится делать несколько запросов к различным эндпоинтам, чтобы получить необходимые данные, что генеририт дополнительную нагрузку и увеличивает время ответа.
🔸 В GraphQL клиент может именно те данные, которые им нужны, указывая в запросах необходимые поля. Это позволяет избежать избыточной или недостаточной выборки данных, сокращая объем ненужной информации, передаваемой между клиентом и сервером.
Схема данных и типизация
🔹 Классический REST не даёт строгих определений по используемым типам и не определяет схему данных. Однако можно использовать, например, спецификацию OpenAPI.
🔸 GraphQL требует определения схемы, которая описывает все данные и их типы, а также способы доступа клиентов к этим данным или их изменения.
Сложнее версионирование API
🔹 В REST мы легко можем внедрить новую версию метода, не прекращая поддержку старой. Например, если для метода получения статей в блоге нужно добавить новый обязательный параметр в теле входящего запроса, то мы можем создать новую версию API метода
POST /v2/articles и добавить новый параметр туда, а POST /v1/articles оставить без изменений. Таким образом, будет соблюдено требование обратной совместимости: потребители смогут пользоваться старой версией пока не перейдут на новую самостоятельно.🔸 GraphQL не поддерживает версионирование по URL, так как у нас только одна точка входа. Однако версионирование можно организовать через создание новых query либо настроить специальные предупреждения для устаревших полей, возвращаемых клиенту.
Сложность кэширования запросов
🔹 Кэширование – это один из 6 принципов REST. В REST мы можем кэшировать запросы к эндпоинтам. Это позволяет снизить нагрузку на серверы и ускоряет получение ответа для клиента.
🔸 Хотя физически в GraphQL можно реализовать кэширование на уровне запросов, в реальности этим не занимаются, так как вариаций запросов может существовать бесчисленное множество. В одном запросе вы можете затребовать имя автора, а в следующем – не только имя автора, но и адрес его электронной почты. Именно для таких случаев вам понадобится более филигранный кэш на уровне полей, а реализовать его не так-то просто. Однако, большинство библиотек, построенных поверх GraphQL, предлагают такие механизмы кэширования прямо «из коробки».
Нет кодов состояний
🔹 REST позволяет возвращать любые доступные коды ответов HTTP, что позволяет клиенту понять результат запроса и среагировать на него.
🔸 GraphQL обычно возвращает статус 200 OK даже с ошибкой, но при использовании специальных клиентов эта проблема легко решается.
❓Что использовать в работе
Итак, REST API применяют, если:
➖ работают с небольшими программами, где нужно обрабатывать простые данные
➖ пользователи работают с ними одинаково
➖ нет требований к сложным запросам
GraphQL выбирают, когда:
➖ у серверного оборудования маленькая пропускная способность и нужно снизить количество ввода-вывода данных
➖ в одном адресе нужно объединить множество источников
➖ запросы пользователей различны, необходимо прорабатывать разные ответы
📎 Ссылки
1. REST API vs GraphQL: в чём между ними разница — МТС
2. В чем разница между GraphQL и REST? — Amazon
3. Сравнение REST и GraphQL
4. GraphQL vs REST: 4 Critical Differences
5. GraphQL vs REST - кто круче? — видео
#сравнение #api #интеграции
👍8❤4🔥4
🚀 Большая подборка открытых API
Собрали для Вас ссылки на примеры API, которое можно подёргать в режиме онлайн прямо на сайтах. Также к большинству ссылок есть документация.
📣 Сохраняйте себе и пересылайте коллегам!
REST API
1. Swagger Petstore — официальный тренажёр от Сваггера
2. Space X API — коллекция Postman (можно и онлайн)
3. VK API — можно онлайн
4. REST API для GitHub + коллекция Postman
5. API ФИАС (КЛАДР)
6. Тренажёр REST Ninja + Swagger-документация
7. API DaData
8. Polygon.io Stocks API — агрегатор API с фондовых бирж США. Есть библиотеки для Python, Go, Javanoscript, PHP, Kotlin
9. Blockchain.com Exchange REST API — сваггер популярной биржи криптовалют
10. Kraken REST API — пример подробной документации API и спецификации в формате OpenAPI + примеры кода на Python
➕ Ещё примеры открытых REST API
GraphQL
1. API GitHub — документация + попробовать онлайн
2. API Space X онлайн
3. Shopify GraphQL API
4. Открытое API с данными о странах + документация и исходники
5. API с данными о товарах Amazon + документация + репозиторий
6. API сайта любителей аниме-манг + документация
➕ Ещё примеры открытых GraphQL API
SOAP
1. Центробанк России
2. Сервис конвертации чисел — онлайн + Postman-коллекция
3. SOAP-песочница
4. PayPal SOAP API
JSON-RPC
1. Обёртка для Solana JSON-RPC, официальная документация
2. Пример OpenRPC + документация
3. Пример документации для JSON-RPC API
4. JSON-RPC API для zkLink
gRPC
1. Google API
2. Google Cloud Bigtable gRPC API
Websockets
1. Binance WebSocket API Documentation — API криптобиржи
2. Gate.io Spot WebSocket v4 — ещё пример от биржи криптовалют, есть примеры кода на Python
3. Polygon.io WebSocket API — агрегатор API с фондовых бирж США. Есть библиотеки для Python, Go, Javanoscript, PHP, Kotlin
4. Blockchain.com Websocket API — документация от популярной биржи криптовалют с примерами кода на Python
5. EXMO Websocket API + пример документации API в Postman (Websockets и REST)
#api #интеграции #подборка
Собрали для Вас ссылки на примеры API, которое можно подёргать в режиме онлайн прямо на сайтах. Также к большинству ссылок есть документация.
📣 Сохраняйте себе и пересылайте коллегам!
REST API
1. Swagger Petstore — официальный тренажёр от Сваггера
2. Space X API — коллекция Postman (можно и онлайн)
3. VK API — можно онлайн
4. REST API для GitHub + коллекция Postman
5. API ФИАС (КЛАДР)
6. Тренажёр REST Ninja + Swagger-документация
7. API DaData
8. Polygon.io Stocks API — агрегатор API с фондовых бирж США. Есть библиотеки для Python, Go, Javanoscript, PHP, Kotlin
9. Blockchain.com Exchange REST API — сваггер популярной биржи криптовалют
10. Kraken REST API — пример подробной документации API и спецификации в формате OpenAPI + примеры кода на Python
➕ Ещё примеры открытых REST API
GraphQL
1. API GitHub — документация + попробовать онлайн
2. API Space X онлайн
3. Shopify GraphQL API
4. Открытое API с данными о странах + документация и исходники
5. API с данными о товарах Amazon + документация + репозиторий
6. API сайта любителей аниме-манг + документация
➕ Ещё примеры открытых GraphQL API
SOAP
1. Центробанк России
2. Сервис конвертации чисел — онлайн + Postman-коллекция
3. SOAP-песочница
4. PayPal SOAP API
JSON-RPC
1. Обёртка для Solana JSON-RPC, официальная документация
2. Пример OpenRPC + документация
3. Пример документации для JSON-RPC API
4. JSON-RPC API для zkLink
gRPC
1. Google API
2. Google Cloud Bigtable gRPC API
Websockets
1. Binance WebSocket API Documentation — API криптобиржи
2. Gate.io Spot WebSocket v4 — ещё пример от биржи криптовалют, есть примеры кода на Python
3. Polygon.io WebSocket API — агрегатор API с фондовых бирж США. Есть библиотеки для Python, Go, Javanoscript, PHP, Kotlin
4. Blockchain.com Websocket API — документация от популярной биржи криптовалют с примерами кода на Python
5. EXMO Websocket API + пример документации API в Postman (Websockets и REST)
#api #интеграции #подборка
🔥34❤14👍9
JSON-RPC: что это такое и чем отличается от REST
JSON-RPC – это простой протокол для создания API в стиле RPC (Remote Procedure Call).
RPC означает Remote Procedure Call, то есть, на бэкенд посылается команда о выполнении некоего кода. Команда по смыслу и предназначению может быть любой.
Все запросы отправляются только в один эндпоинт. Для отправки запросов в качестве транспорта может использоваться что угодно, но как правило, используется протокол HTTP, а точнее, лишь только один его метод – POST.
Как вы поняли из названия, все сообщения представляются в формате JSON. В отличие от REST, JSON-RPC вводит требования к составу запросов и ответов – они должны включать обязательные элементы.
➡️ Запросы могут содержать следующие свойства:
1. jsonrpc — версия JSON-RPC (актуальная 2.0)
2. method – строка с именем вызываемого метода
3. params – массив данных, передаваемых на сервер
4. id – значение любого типа, которое используется для установки соответствия между запросом и ответом.
⬅️ Ответы сервера должны содержать следующие элементы:
1. jsonrpc — версия JSON-RPC (актуальная 2.0)
2. result – данные в случае успеха; error — код ошибки, если произошла ошибка
3. id – то же значение, что и в запросе, к которому относится данный ответ
Примеры запросов и ответов
Запрос
✅ Ещё пара фишек JSON-RPC
1. Запросы можно группировать в пакеты, подобно gRPC.
2. Можно отправлять запросы-уведомления, не требующие ответа от сервера (в таком случае не передаётся id в запросе).
🚧 Ограничения JSON-RPC
➖ Сложность кэширования. RPC не поддерживает использование инфраструктурного кэширования (например, CDN), так как использует только метод POST, который не является идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты.
➖ Сложность балансировки нагрузки. Балансировка нагрузки в JSON-RPC не так проста и эффективна, как в REST, который предлагает разные HTTP-методы, коды ответов и заголовки для управления балансировкой нагрузки
В случае возникновения ошибок на одной из нод, JSON-RPC не может перенаправить запрос на другую ноду, в отличие от REST, который использует коды ответов HTTP и заголовки для управления балансировкой нагрузки.
➖ Снижение уровня абстракции. Парадигма RPC требует от клиента большей погружённости и связанности с уровнем реализации, чем REST. Клиент должен знать, какие процедуры вызывать на сервере, какие параметры передавать и какой формат ответа ожидать. REST имеет выше уровень абстракции, чем JSON-RPC, потому что он отделяет ресурсы в системе от способа доступа к ним. Клиенту не нужно знать, как сервер реализует свою логику, а достаточно знать, какие ресурсы доступны, какие HTTP-методы применимы к ним и какой формат данных используется.
➖ Нет поддержки кодов состояний HTTP.
Когда лучше использовать JSON-RPC вместо REST
Как обычно: нет лучшего рецепта и всё зависит от ситуации.
JSON-RPC может оказаться эффективнее, когда:
1️⃣ Требуются сложные вычисления (HTTP-глаголов недостаточно), затрагивающие множество действий и объектов.
2️⃣ Предметная область специфична и не поддаётся адекватному разбиению на ресурсы, а всё взаимодействие заключается в запуске удалённых процедур.
3️⃣ Требуется работать над другими каналами передачи данных, кроме HTTP, или поддерживать открытое соединение (например, через WebSockets).
📎 Материалы
1. REST? Возьмите тупой JSON-RPC
2. Статьи от разработчика-адепта JSON-RPC: часть 1, часть 2
3. JSON-RPC? Возьмите хитрый REST — критика JSON-RPC
4. Обзорная статья от Merion Academy
5. Видео JSON-RPC или когда REST неудобен
#api #интеграции
JSON-RPC – это простой протокол для создания API в стиле RPC (Remote Procedure Call).
RPC означает Remote Procedure Call, то есть, на бэкенд посылается команда о выполнении некоего кода. Команда по смыслу и предназначению может быть любой.
Все запросы отправляются только в один эндпоинт. Для отправки запросов в качестве транспорта может использоваться что угодно, но как правило, используется протокол HTTP, а точнее, лишь только один его метод – POST.
Как вы поняли из названия, все сообщения представляются в формате JSON. В отличие от REST, JSON-RPC вводит требования к составу запросов и ответов – они должны включать обязательные элементы.
➡️ Запросы могут содержать следующие свойства:
1. jsonrpc — версия JSON-RPC (актуальная 2.0)
2. method – строка с именем вызываемого метода
3. params – массив данных, передаваемых на сервер
4. id – значение любого типа, которое используется для установки соответствия между запросом и ответом.
⬅️ Ответы сервера должны содержать следующие элементы:
1. jsonrpc — версия JSON-RPC (актуальная 2.0)
2. result – данные в случае успеха; error — код ошибки, если произошла ошибка
3. id – то же значение, что и в запросе, к которому относится данный ответ
Примеры запросов и ответов
Запрос
{"jsonrpc": "2.0", "method": "post.like", "params": {"post": "12345"}, "id": 1}
Успешный ответ{"jsonrpc": "2.0", "result": {"likes": 123}, "id": 1}
Ответ с ошибкой{"jsonrpc": "2.0", "error": {"code": 666, "message": "Post not found"}, "id": "1"}
Таким образом, JSON-RPC более формализован, чем REST. Потенциально это может уменьшить количество разногласий и разночтений в команде, однако обратная сторона формализации – снижение гибкости.✅ Ещё пара фишек JSON-RPC
1. Запросы можно группировать в пакеты, подобно gRPC.
2. Можно отправлять запросы-уведомления, не требующие ответа от сервера (в таком случае не передаётся id в запросе).
🚧 Ограничения JSON-RPC
➖ Сложность кэширования. RPC не поддерживает использование инфраструктурного кэширования (например, CDN), так как использует только метод POST, который не является идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты.
➖ Сложность балансировки нагрузки. Балансировка нагрузки в JSON-RPC не так проста и эффективна, как в REST, который предлагает разные HTTP-методы, коды ответов и заголовки для управления балансировкой нагрузки
В случае возникновения ошибок на одной из нод, JSON-RPC не может перенаправить запрос на другую ноду, в отличие от REST, который использует коды ответов HTTP и заголовки для управления балансировкой нагрузки.
➖ Снижение уровня абстракции. Парадигма RPC требует от клиента большей погружённости и связанности с уровнем реализации, чем REST. Клиент должен знать, какие процедуры вызывать на сервере, какие параметры передавать и какой формат ответа ожидать. REST имеет выше уровень абстракции, чем JSON-RPC, потому что он отделяет ресурсы в системе от способа доступа к ним. Клиенту не нужно знать, как сервер реализует свою логику, а достаточно знать, какие ресурсы доступны, какие HTTP-методы применимы к ним и какой формат данных используется.
➖ Нет поддержки кодов состояний HTTP.
Когда лучше использовать JSON-RPC вместо REST
Как обычно: нет лучшего рецепта и всё зависит от ситуации.
JSON-RPC может оказаться эффективнее, когда:
1️⃣ Требуются сложные вычисления (HTTP-глаголов недостаточно), затрагивающие множество действий и объектов.
2️⃣ Предметная область специфична и не поддаётся адекватному разбиению на ресурсы, а всё взаимодействие заключается в запуске удалённых процедур.
3️⃣ Требуется работать над другими каналами передачи данных, кроме HTTP, или поддерживать открытое соединение (например, через WebSockets).
📎 Материалы
1. REST? Возьмите тупой JSON-RPC
2. Статьи от разработчика-адепта JSON-RPC: часть 1, часть 2
3. JSON-RPC? Возьмите хитрый REST — критика JSON-RPC
4. Обзорная статья от Merion Academy
5. Видео JSON-RPC или когда REST неудобен
#api #интеграции
🔥14❤9👍4
Forwarded from Библиотека Системного Аналитика
Impact_Mapping_Как_повысить_эффективность_программных_продуктов.pdf
3.9 MB
Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке
✍️ Автор: Гойко Аджич
📅 Год: 2017
🔤 Язык: русский
Эта книга — практическое пособие по impact mapping (картам влияния), простому, но очень эффективному методу разработки программного обеспечения. Он помогает еще на стадии стратегического планирования организовать сотрудничество различных специалистов и в результате создавать эффективные программные продукты.
Почему книга достойна прочтения:
— Impact maps позволяют составлять планы, которые обеспечат соответствие разрабатываемого программного обеспечения бизнес-целям организации.
— Они также помогают легко адаптировать программное обеспечение в ходе работы над проектом.
— Этот инструмент универсален и подойдет как для Agile-проектов, так и для классического проектного подхода.
Обзор книги на vc.ru
#планирование #стратегия
✍️ Автор: Гойко Аджич
📅 Год: 2017
🔤 Язык: русский
Эта книга — практическое пособие по impact mapping (картам влияния), простому, но очень эффективному методу разработки программного обеспечения. Он помогает еще на стадии стратегического планирования организовать сотрудничество различных специалистов и в результате создавать эффективные программные продукты.
Почему книга достойна прочтения:
— Impact maps позволяют составлять планы, которые обеспечат соответствие разрабатываемого программного обеспечения бизнес-целям организации.
— Они также помогают легко адаптировать программное обеспечение в ходе работы над проектом.
— Этот инструмент универсален и подойдет как для Agile-проектов, так и для классического проектного подхода.
Обзор книги на vc.ru
#планирование #стратегия
👍14🔥3👎1
🛡Безопасность API: базовые принципы
Проектирование API не ограничивается реализацией HTTP запросов в определенном стиле и формированием ответов в соответствии со спецификацией. Крайне важно уделить внимание вопросам безопасности.
Способы обеспечения безопасности
1️⃣ Использование зашифрованного протокола TLS. Рекомендуется шифровать трафик запросов и ответов API для защиты конфиденциальности информации при передаче по незащищенным сетям. Общепринятой практикой является использование протокола шифрования TLS. Поверх TLS работает HTTPS, о котором мы уже писали.
2️⃣ Авторизация запросов. Авторизация подразумевает, что данному клиенту разрешено выполнять операцию над ресурсом. Следует учитывать:
▪️Проверку прав доступа к объектам при каждом запросе.
▪️Проверку того, что залогиненный пользователь имеет доступ только к разрешенным объектам.
▪️ID объектов должны быть сложными для подбора, например в виде UUID, а не простая последовательность 1, 2, 3.
3️⃣ Проверка содержимого запроса. Необходимо проверять, что запрос не содержит опасных компонентов (например, SQL-инъекции, XSS-атаки, DTD-атаки). При этом недопустимо автоматически десериализовать пришедшие данные и записывать их в БД без каких-либо проверок бизнес-логики и прав доступа.
4️⃣ Проверка скорости и количества запросов: контроль, что запросы API не превышают определенной скорости для защиты сервиса от перегрузки или атак. Может настраивать квоты запросов на клиента. Сюда входит, например, блокировка IP по результатам неудачных попыток входа.
5️⃣ Контроль размера запроса: проверяет, что полезная нагрузка запроса не превышает ограничения для операции API. Предотвращает попадание неправильных (больших) запросов к сервису.
6️⃣ Мониторинг безопасности: логировние ключевых событий, таких как неудачные попытки аутентификации, отказы в доступе, ошибки валидации входных данных. Также следует мониторить инфраструктуру, сетевую активность, загрузку ОС. Важно настроить алерты, чтобы максимально оперативно реагировать на риски.
7️⃣ Если API непубличное, следует ограничить адреса, с которых разрешено использование API. Также можно ограничивать HTTP методы, которые могут быть использованы для доступа к API и задать список заголовков, которые сервер может принимать.
📄 Стандарты в области безопасности API
1. OWASP (Open Web Application Security Project), а также есть стьтья-перевод на русском на Хабре
2. RFC 7519 — JSON Web Token (JWT)
3. OAuth 2.0, простым языком: статья на Хабре
📑 Статьи
1. Безопасность REST API от А до ПИ
2. Рекомендации по проектированию безопасности API для внутренних и облачных систем
3. Требования аутентификации и авторизации API — раздел открытого курса по документированию API
4. Защита API от атак — статья на Tadviser от ИБ-компании
5. Требования к информационной безопасности: кого вовлекать в выявление? — статья Алексея Краснова на Systems.Education
⏯ Видео
1. Защита API и микросервисной инфраструктуры — доклад директора ИБ-компании
2. Тестирование безопасности API — Катерина Овеченко. QA Fest 2019
3. Курс видеолекций "Безопасность интернет-приложений" от Mail.ru Group, МГТУ им. Н.Э. Баумана (осень 2014)
4. Основы безопасности веб-приложений — вебинар от Skillbox
5. Открытая лекция Академии Яндекса про безопасность веб-приложений (2017)
6. Информационная безопасность в аналитике — доклад Галины Матвеевой на конференции Analyst Days-9
7. Информационная безопасность и криптография. Точка зрения аналитика — доклад Сергея Евтуховича на конференции Analyst Days #15
Инфографика по безопасности API
#безопасность #api
Проектирование API не ограничивается реализацией HTTP запросов в определенном стиле и формированием ответов в соответствии со спецификацией. Крайне важно уделить внимание вопросам безопасности.
Способы обеспечения безопасности
1️⃣ Использование зашифрованного протокола TLS. Рекомендуется шифровать трафик запросов и ответов API для защиты конфиденциальности информации при передаче по незащищенным сетям. Общепринятой практикой является использование протокола шифрования TLS. Поверх TLS работает HTTPS, о котором мы уже писали.
2️⃣ Авторизация запросов. Авторизация подразумевает, что данному клиенту разрешено выполнять операцию над ресурсом. Следует учитывать:
▪️Проверку прав доступа к объектам при каждом запросе.
▪️Проверку того, что залогиненный пользователь имеет доступ только к разрешенным объектам.
▪️ID объектов должны быть сложными для подбора, например в виде UUID, а не простая последовательность 1, 2, 3.
3️⃣ Проверка содержимого запроса. Необходимо проверять, что запрос не содержит опасных компонентов (например, SQL-инъекции, XSS-атаки, DTD-атаки). При этом недопустимо автоматически десериализовать пришедшие данные и записывать их в БД без каких-либо проверок бизнес-логики и прав доступа.
4️⃣ Проверка скорости и количества запросов: контроль, что запросы API не превышают определенной скорости для защиты сервиса от перегрузки или атак. Может настраивать квоты запросов на клиента. Сюда входит, например, блокировка IP по результатам неудачных попыток входа.
5️⃣ Контроль размера запроса: проверяет, что полезная нагрузка запроса не превышает ограничения для операции API. Предотвращает попадание неправильных (больших) запросов к сервису.
6️⃣ Мониторинг безопасности: логировние ключевых событий, таких как неудачные попытки аутентификации, отказы в доступе, ошибки валидации входных данных. Также следует мониторить инфраструктуру, сетевую активность, загрузку ОС. Важно настроить алерты, чтобы максимально оперативно реагировать на риски.
7️⃣ Если API непубличное, следует ограничить адреса, с которых разрешено использование API. Также можно ограничивать HTTP методы, которые могут быть использованы для доступа к API и задать список заголовков, которые сервер может принимать.
📄 Стандарты в области безопасности API
1. OWASP (Open Web Application Security Project), а также есть стьтья-перевод на русском на Хабре
2. RFC 7519 — JSON Web Token (JWT)
3. OAuth 2.0, простым языком: статья на Хабре
📑 Статьи
1. Безопасность REST API от А до ПИ
2. Рекомендации по проектированию безопасности API для внутренних и облачных систем
3. Требования аутентификации и авторизации API — раздел открытого курса по документированию API
4. Защита API от атак — статья на Tadviser от ИБ-компании
5. Требования к информационной безопасности: кого вовлекать в выявление? — статья Алексея Краснова на Systems.Education
⏯ Видео
1. Защита API и микросервисной инфраструктуры — доклад директора ИБ-компании
2. Тестирование безопасности API — Катерина Овеченко. QA Fest 2019
3. Курс видеолекций "Безопасность интернет-приложений" от Mail.ru Group, МГТУ им. Н.Э. Баумана (осень 2014)
4. Основы безопасности веб-приложений — вебинар от Skillbox
5. Открытая лекция Академии Яндекса про безопасность веб-приложений (2017)
6. Информационная безопасность в аналитике — доклад Галины Матвеевой на конференции Analyst Days-9
7. Информационная безопасность и криптография. Точка зрения аналитика — доклад Сергея Евтуховича на конференции Analyst Days #15
Инфографика по безопасности API
#безопасность #api
👍9🔥8❤3👏2
Шифрование, хэширование, хэширование с солью и маскирование — разбираемся в понятиях криптографии.
Ставьте ⚡️, если формат карточек понравился
#безопасность
Ставьте ⚡️, если формат карточек понравился
#безопасность
⚡97❤7🔥7
💥Подборка от канала Системный сдвиг 💥
Ведет канал Юрий Куприянов — эксперт по системному анализу, управлению продуктами и архитектуре, автор лучших докладов на конференциях для системных аналитиков:
AnalystDays, Летний аналитический фестиваль, Flow.
Первым исследовал возможности ChatGPT применительно к системному анализу. В канале есть материалы и обсуждения докладов, и много полезных инструментов и практик.
Топ самых полезных постов:
📛 Про стоп-слова для аналитика (если вы их встретили в требованиях -- остановитесь и перепишите!)
✅ 10 техник проверки полноты требований
📝 Паттерны декомпозиции пользовательских историй
🤢 Как не быть душным при общении с пользователями?
🤷🏼♂️ Про самые неинтересные аналитикам темы
Посты про ChatGPT:
🤖 ChatGPT генерит техническое задание
👾Архитектурная модель C4 и её генерация
📆Про ChatGPT и оценку сроков проекта
🏆Задание для аналитика на собеседовании и как его проходит ChatGPT
Ведет канал Юрий Куприянов — эксперт по системному анализу, управлению продуктами и архитектуре, автор лучших докладов на конференциях для системных аналитиков:
AnalystDays, Летний аналитический фестиваль, Flow.
Первым исследовал возможности ChatGPT применительно к системному анализу. В канале есть материалы и обсуждения докладов, и много полезных инструментов и практик.
Топ самых полезных постов:
📛 Про стоп-слова для аналитика (если вы их встретили в требованиях -- остановитесь и перепишите!)
✅ 10 техник проверки полноты требований
📝 Паттерны декомпозиции пользовательских историй
🤢 Как не быть душным при общении с пользователями?
🤷🏼♂️ Про самые неинтересные аналитикам темы
Посты про ChatGPT:
🤖 ChatGPT генерит техническое задание
👾Архитектурная модель C4 и её генерация
📆Про ChatGPT и оценку сроков проекта
🏆Задание для аналитика на собеседовании и как его проходит ChatGPT
Telegram
Системный сдвиг
Авторский канал Юрия Куприянова. Обучаю системных аналитиков. Пишу про нетривиальные темы в анализе, проектировании систем, управлении и обучении.
Программный директор WAW, член ПК Flow, ЛАФ.
Контакты: @YuryKupriyanov
Курсы: https://systems.education
Программный директор WAW, член ПК Flow, ЛАФ.
Контакты: @YuryKupriyanov
Курсы: https://systems.education
👍11❤3🔥2
💠 Микросервисная архитектура: основные понятия
Микросервисная архитектура — это подход к разработке, при котором система разделяется на слабо связанные друг с другом части, которые разрабатываются и развёртываются независимо друг от друга.
У каждого микросервиса своя бизнес-задача: управлять каталогом, хранить содержимое корзины или проводить оплату заказа. При этом разные микросервисы могут быть реализованы на разных языках программирования и использовать разные СУБД.
🔲 Альтернатива монолиту
Большинство систем, разработанных ранее, построены на монолитной архитектуре. Это тяжеловесные приложения, с огромным количеством строк кода, который часто не документирован и не читаем.
Вносить изменения в такую систему крайне сложно: малейшее изменение кода может вызвать баги в самых неожиданных местах. А ведь любой баг уронит сразу всю систему! А ещё монолит можно релизить только вест целиком.
Микросервисная архитектура предлагает альтернативу монолиту.
✅ Преимущества микросервисной архитектуры
1️⃣ Сокращение Time To Market. Главная цель перехода на микросервисы – увеличение скорости поставки конечной ценности на рынок, или, по-айтишному, сокращение длительности релизного цикла. Если эта цель не выполняется, стоит задуматься, а зачем вам микросервисы.
2️⃣ Масштабируемость. Микросервисы можно масштабировать независимо друг от друга. Например, если возрастает нагрузка на какой-либо сервис, можно создать дополнительные реплики этого сервиса или увеличить вычислительные мощности, не затрагивая систему в целом.
3️⃣ Отказоустойчивость. При падении одного из микросервисов система в целом продолжает функционировать.
4️⃣ Гибкость технологий. Любой микросервис по отдельности можно реализовывать на каком угодно техстеке.
⛔️ Недостатки микросервисной архитектуры
1️⃣ Это дорого. Требуется больше железа и людских ресурсов.
2️⃣ Это сложно. Сложно правильно декомпозировать предметную область и грамотно определить границы сервисов. Сложно искать ошибки, так как приходится применять специальные системы трейсинга. Сложно обеспечить мониторинг.
3️⃣ Сложно поддерживать целостность данных. Если в монолите у нас общая реляционная БД, то и схема данных у нас общая. Целостность и транзакционность находятся под контролем СУБД. В микросервисной архитектуре у каждого сервиса своя БД, а значит нет единой системы, которая бы гарантировала целостность транзакций.
❓ Когда стоит переходить на микросервисы
🔹 Монолит ограничивает эффективность бизнеса. Вносить изменения в код практически невозможно. Релизы очень сложны и долги. Ошибки приводят к большим финансовым и репутационным потерям.
🔹 Есть деньги, ресурсы и компетенции.
🔹 У вас крупный проект с большим количеством разработчиков.
🔹 Вы отлично понимаете свою предметную область. Без этого верно определить границы микросервисов нельзя.
🔹 Вы понимаете, как будут работать распределённые транзакции
❌ Когда не стоит переходить на микросервисы
➖ Малый размер проекта. Если у вас проект маленький или средний по размеру, миграция на микросервисы может привести к ненужной сложности и издержкам.
➖ Не хватает ресурсов. Микросервисы — это дорого и сложно. Если у вас нет достаточно разработчиков, времени, денег, лучше не пытатьсях.
➖ Команда не готова. Микросервисы требуют специальных навыков и знаний. Если ваша команда не имеет их или не хочет менять архитектуру, это может вызвать проблемы.
➖ Текущая архитектура работает. Если ваш монолитный проект устойчив и соответствует потребностям бизнеса.
➖ Нужен быстрый старт. Если вам нужно скорее запустить проект и получить фидбек от пользователей, микросервисы могут замедлить процесс.
➖ Высокие требования к согласованности данных. Микросервисы используют разные базы данных для разных сервисов, что может создавать сложности при согласовании данных.
➖ Тесная связанность компонентов: Если компоненты приложения не могут быть изолированы, переход на микросервисы может быть слишком дорогим.
Подборка материалов про микросервисы — в следующем посте 👈
#микросервисы #архитектура
Микросервисная архитектура — это подход к разработке, при котором система разделяется на слабо связанные друг с другом части, которые разрабатываются и развёртываются независимо друг от друга.
У каждого микросервиса своя бизнес-задача: управлять каталогом, хранить содержимое корзины или проводить оплату заказа. При этом разные микросервисы могут быть реализованы на разных языках программирования и использовать разные СУБД.
🔲 Альтернатива монолиту
Большинство систем, разработанных ранее, построены на монолитной архитектуре. Это тяжеловесные приложения, с огромным количеством строк кода, который часто не документирован и не читаем.
Вносить изменения в такую систему крайне сложно: малейшее изменение кода может вызвать баги в самых неожиданных местах. А ведь любой баг уронит сразу всю систему! А ещё монолит можно релизить только вест целиком.
Микросервисная архитектура предлагает альтернативу монолиту.
✅ Преимущества микросервисной архитектуры
1️⃣ Сокращение Time To Market. Главная цель перехода на микросервисы – увеличение скорости поставки конечной ценности на рынок, или, по-айтишному, сокращение длительности релизного цикла. Если эта цель не выполняется, стоит задуматься, а зачем вам микросервисы.
2️⃣ Масштабируемость. Микросервисы можно масштабировать независимо друг от друга. Например, если возрастает нагрузка на какой-либо сервис, можно создать дополнительные реплики этого сервиса или увеличить вычислительные мощности, не затрагивая систему в целом.
3️⃣ Отказоустойчивость. При падении одного из микросервисов система в целом продолжает функционировать.
4️⃣ Гибкость технологий. Любой микросервис по отдельности можно реализовывать на каком угодно техстеке.
⛔️ Недостатки микросервисной архитектуры
1️⃣ Это дорого. Требуется больше железа и людских ресурсов.
2️⃣ Это сложно. Сложно правильно декомпозировать предметную область и грамотно определить границы сервисов. Сложно искать ошибки, так как приходится применять специальные системы трейсинга. Сложно обеспечить мониторинг.
3️⃣ Сложно поддерживать целостность данных. Если в монолите у нас общая реляционная БД, то и схема данных у нас общая. Целостность и транзакционность находятся под контролем СУБД. В микросервисной архитектуре у каждого сервиса своя БД, а значит нет единой системы, которая бы гарантировала целостность транзакций.
❓ Когда стоит переходить на микросервисы
🔹 Монолит ограничивает эффективность бизнеса. Вносить изменения в код практически невозможно. Релизы очень сложны и долги. Ошибки приводят к большим финансовым и репутационным потерям.
🔹 Есть деньги, ресурсы и компетенции.
🔹 У вас крупный проект с большим количеством разработчиков.
🔹 Вы отлично понимаете свою предметную область. Без этого верно определить границы микросервисов нельзя.
🔹 Вы понимаете, как будут работать распределённые транзакции
❌ Когда не стоит переходить на микросервисы
➖ Малый размер проекта. Если у вас проект маленький или средний по размеру, миграция на микросервисы может привести к ненужной сложности и издержкам.
➖ Не хватает ресурсов. Микросервисы — это дорого и сложно. Если у вас нет достаточно разработчиков, времени, денег, лучше не пытатьсях.
➖ Команда не готова. Микросервисы требуют специальных навыков и знаний. Если ваша команда не имеет их или не хочет менять архитектуру, это может вызвать проблемы.
➖ Текущая архитектура работает. Если ваш монолитный проект устойчив и соответствует потребностям бизнеса.
➖ Нужен быстрый старт. Если вам нужно скорее запустить проект и получить фидбек от пользователей, микросервисы могут замедлить процесс.
➖ Высокие требования к согласованности данных. Микросервисы используют разные базы данных для разных сервисов, что может создавать сложности при согласовании данных.
➖ Тесная связанность компонентов: Если компоненты приложения не могут быть изолированы, переход на микросервисы может быть слишком дорогим.
Подборка материалов про микросервисы — в следующем посте 👈
#микросервисы #архитектура
👍16❤8🔥6