This media is not supported in your browser
VIEW IN TELEGRAM
🔐 SSL/TLS-сертификаты для обеспечения HTTPS 🔐
Чтобы обеспечить безопасное HTTPS соединение и защититься от перехвата трафика, на сервере должны быть установлены SSL/TLS-сертификаты.
👉 SSL/TLS-сертификат - это цифровой документ, который:
▫️ подтверждает подлинность сервера (что api.company.com это действительно ваш сервер, а не подделка),
▫️ содержит публичный ключ для шифрования данных при установлении TLS-соединения.
Когда клиент заходит по https://.., он получает этот сертификат и проверяет его подлинность через цепочку доверенных центров сертификации (CA — Certificate Authority)
👉 Центр сертификации - это доверенная организация, которая подтверждает подлинность домена или компании и выдаёт цифровые сертификаты (SSL/TLS).
Каждая операционная система (Windows, macOS, Android и др) и каждый браузер имеет внутри себя список доверенных корневых сертификатов (Root CA).
Это десятки (иногда сотни) организаций:
+ DigiCert
+ GlobalSign
+ Let’s Encrypt
+ GoDaddy
и др.
📦 Этот список устанавливается вместе с системой и регулярно обновляется вместе с обновлением браузера или ОС.
👉 Что происходит, когда ты заходишь на HTTPS://getanalyst.ru, у которого есть SSL/TLS?
1️⃣ Клиент (Postman, браузер, моб. приложение) устанавливает TCP-соединение с сервером (порт 443)
2️⃣ Сервер отправляет свой сертификат (в нём: имя домена, срок действия, кто выдал и т.д.)
3️⃣ Клиент проверяет подпись этого сертификата
👉 Что происходит, когда ты заходишь на https://getanalysts.com?
Браузер сообщает, что соединение небезопасно
📌 Что можно написать в ТЗ про проверку HTTPS (SSL/TLS), в задачах на интеграции по API:
✅ Все внешние и внутренние интеграции - только по HTTPS (TLS ≥ 1.2, желательно TLS 1.3)
✅ Валидировать сертификаты на стороне клиента; логировать certificate errors
✅ Использовать mTLS для сервер-серверных вызовов критичных API (для повышенной безопасности)
✅ Не передавать секреты или CVV в query-параметрах (в URL) - только в теле по HTTPS
✅ Логировать подозрительную активность авторизаций
#RestApiGA #АрхитектураGA
Чтобы обеспечить безопасное HTTPS соединение и защититься от перехвата трафика, на сервере должны быть установлены SSL/TLS-сертификаты.
👉 SSL/TLS-сертификат - это цифровой документ, который:
▫️ подтверждает подлинность сервера (что api.company.com это действительно ваш сервер, а не подделка),
▫️ содержит публичный ключ для шифрования данных при установлении TLS-соединения.
Когда клиент заходит по https://.., он получает этот сертификат и проверяет его подлинность через цепочку доверенных центров сертификации (CA — Certificate Authority)
👉 Центр сертификации - это доверенная организация, которая подтверждает подлинность домена или компании и выдаёт цифровые сертификаты (SSL/TLS).
Каждая операционная система (Windows, macOS, Android и др) и каждый браузер имеет внутри себя список доверенных корневых сертификатов (Root CA).
Это десятки (иногда сотни) организаций:
+ DigiCert
+ GlobalSign
+ Let’s Encrypt
+ GoDaddy
и др.
📦 Этот список устанавливается вместе с системой и регулярно обновляется вместе с обновлением браузера или ОС.
👉 Что происходит, когда ты заходишь на HTTPS://getanalyst.ru, у которого есть SSL/TLS?
1️⃣ Клиент (Postman, браузер, моб. приложение) устанавливает TCP-соединение с сервером (порт 443)
2️⃣ Сервер отправляет свой сертификат (в нём: имя домена, срок действия, кто выдал и т.д.)
3️⃣ Клиент проверяет подпись этого сертификата
👉 Что происходит, когда ты заходишь на https://getanalysts.com?
Браузер сообщает, что соединение небезопасно
📌 Что можно написать в ТЗ про проверку HTTPS (SSL/TLS), в задачах на интеграции по API:
✅ Все внешние и внутренние интеграции - только по HTTPS (TLS ≥ 1.2, желательно TLS 1.3)
✅ Валидировать сертификаты на стороне клиента; логировать certificate errors
✅ Использовать mTLS для сервер-серверных вызовов критичных API (для повышенной безопасности)
✅ Не передавать секреты или CVV в query-параметрах (в URL) - только в теле по HTTPS
✅ Логировать подозрительную активность авторизаций
#RestApiGA #АрхитектураGA
🔥21❤🔥5❤4👍4🤩1
GET, POST, PUT, PATCH и DELETE - виды методов, часть протокола HTTP. Используются в архитектурном стиле REST API.
Нужны, чтобы стандартизировать взаимодействие между клиентом и сервером.
Каждый метод выполняет определённое действие и соответствует логике CRUD-модели (Create, Read, Update, Delete).
🩷 GET - Чтение данных
Не поддерживает тело - Body (JSON).
Идемпотентен.
💚 POST - Создание ресурсов (объектов в БД)
Поддерживает тело - Body (JSON).
Не идемпотентен.
* Исключения, когда POST используют для чтения: сложные запросы с большим кол-вом фильтров, асинхронные операции.
** Почему в некоторых REST API все POST? Потому что они не REST API, а HTTP API.
💙 PUT - Полная замена и/или создание ресурса
В теле JSON требует полный объект.
Идемпотентен.
* Часто используют только для изменения.
💜 PATCH - Частичное обновление ресурса
В теле JSON передаются только те поля объекта, которые нужно изменить.
Не идемпотентен.
❤️ DELETE - Удаление ресурса.
Не поддерживает тело - Body (JSON).
Идемпотентен.
💛 А что по поводу TRACE, HEAD, OPTIONS, CONNECT?
Могут быть заменены GET-ом.
Очень маленький шанс встретить или применить на практике.
Правильное использование HTTP-методов в REST API упрощает взаимодействие с вашей системой, так как делает API предсказуемым и удобным для разработчиков.
P.S. Ссылка на подкаст про идемпотентность и коммутативность в API
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19❤4🔥4❤🔥2💯2👌1
📗 REST API - 6 главных принципов, про которые спрашивают на собеседованиях 📗
REST API — это архитектурный стиль для создания веб-сервисов, основанный на протоколе HTTP.
То, что REST API основан на протоколе HTTP, означает, что все принципы работы, структура запросов и ответов, будут также применимы и для REST API.
Архитектурный стиль REST приносит для HTTP дополнительные правила и принципы, по которым должен происходить обмен данными в Интернете 👇
Главные принципы REST:
1. Строгое разделение клиента и сервера
2. Единый интерфейс
3. Без сохранения состояния (Stateless)
4. Многоуровневая система
5. Кэширование
6. Выполнение кода по запросу
В картинках к посту просто и с примерами разобрала эти принципы.
Это не самая ценная в работе информация, но перечень этих принципов и их понимание могут спрашивать на собеседованиях 👌
#RestApiGA
REST API — это архитектурный стиль для создания веб-сервисов, основанный на протоколе HTTP.
То, что REST API основан на протоколе HTTP, означает, что все принципы работы, структура запросов и ответов, будут также применимы и для REST API.
Архитектурный стиль REST приносит для HTTP дополнительные правила и принципы, по которым должен происходить обмен данными в Интернете 👇
Главные принципы REST:
1. Строгое разделение клиента и сервера
2. Единый интерфейс
3. Без сохранения состояния (Stateless)
4. Многоуровневая система
5. Кэширование
6. Выполнение кода по запросу
В картинках к посту просто и с примерами разобрала эти принципы.
Это не самая ценная в работе информация, но перечень этих принципов и их понимание могут спрашивать на собеседованиях 👌
#RestApiGA
❤20🔥7👍3❤🔥2
📚 Книги по API, которые рекомендую к прочтению 📚
Если вы хотите научиться проектировать REST API или готовитесь к собеседованиям на системного аналитика, то это одни из немногих книг, которые реально формируют мышление «API-дизайнера», а не просто перечисляют HTTP-методы 👇
📚 "Проектирование веб-API", Лоре Арно
Цитаты:
✅ Что вы делаете, когда впервые используете какую-либо повседневную вещь? Вы внимательно смотрите на ее интерфейс, чтобы определить ее назначение и то, как ее использовать, основываясь на том, что вы видите, и на своем прошлом опыте. И здесь важен дизайн.
✅ Если вы сосредоточитесь на том, что происходит «под капотом», это приведет к полной катастрофе. Если сфокусироваться на том, что могут делать пользователи, – все пройдет гладко.
✅ Любое представление должно быть легко понятно для людей и программ.
🔗 Читать отрывок
📚 "RESTful Web API паттерны и практики. Связывание и оркестрация микросервисов и распределение данных", Майк Амундсен
Цитаты:
✅ Основной сложностью проектирования успешных API сервисов является необходимость балансировать между стабильностью и возможностью развиваться.
✅ Одной из сложностей при создании гибких клиентов API является обработка всех деталей каждого НТТР-запроса.
🔗 Купить на Литрес
🔗 Читать отрывок
Добавляйте в свой TO DO лист к прочтению 🤝
#RestApiGA
Если вы хотите научиться проектировать REST API или готовитесь к собеседованиям на системного аналитика, то это одни из немногих книг, которые реально формируют мышление «API-дизайнера», а не просто перечисляют HTTP-методы 👇
📚 "Проектирование веб-API", Лоре Арно
Цитаты:
✅ Что вы делаете, когда впервые используете какую-либо повседневную вещь? Вы внимательно смотрите на ее интерфейс, чтобы определить ее назначение и то, как ее использовать, основываясь на том, что вы видите, и на своем прошлом опыте. И здесь важен дизайн.
✅ Если вы сосредоточитесь на том, что происходит «под капотом», это приведет к полной катастрофе. Если сфокусироваться на том, что могут делать пользователи, – все пройдет гладко.
✅ Любое представление должно быть легко понятно для людей и программ.
📚 "RESTful Web API паттерны и практики. Связывание и оркестрация микросервисов и распределение данных", Майк Амундсен
Цитаты:
✅ Основной сложностью проектирования успешных API сервисов является необходимость балансировать между стабильностью и возможностью развиваться.
✅ Одной из сложностей при создании гибких клиентов API является обработка всех деталей каждого НТТР-запроса.
Добавляйте в свой TO DO лист к прочтению 🤝
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤28🔥9❤🔥3
Помимо обучений для опытных специалистов, в GetAnalyst есть программа «Системный аналитик: с нуля до опыта работы на проекте» 🙌 #студентыGetAnalyst
Александра пришла на программу, так как решила сменить профессию на IT.
Привлекло то, что отовсюду звучала реклама о том, как легко войти в эту сферу.
Так ли это? Своим опытом она поделилась с нами⬆️
‐‐--------------
Друзья, программа «Системный аналитик: с нуля до опыта работы на проекте» подходит тем, кто хочет:
✅ начать карьеру в аналитике с нуля,
✅ перейти из других IT-специализаций (технические писатели, тестировщики, менеджеры проектов или специалисты, сотрудничающие с IT-отделами в компаниях) и освоить навыки сразу трёх профессий: системный аналитик, бизнес-аналитик и менеджер проектов.
👉 Также подойдёт действующим младшим системным аналитикам, которые хотят структурировать знания и получить новый уникальный опыт.
📅 Старт программы 25 сентября.
Перед обучением проводим вводное интервью, чтобы вы смогли разобраться подходит ли вам программа. Разберём текущую ситуацию, зададим вопросы и дадим рекомендации от эксперта.
Записаться на интервью и узнать подробности о курсе можно здесь.
Александра пришла на программу, так как решила сменить профессию на IT.
Привлекло то, что отовсюду звучала реклама о том, как легко войти в эту сферу.
Так ли это? Своим опытом она поделилась с нами⬆️
‐‐--------------
Друзья, программа «Системный аналитик: с нуля до опыта работы на проекте» подходит тем, кто хочет:
✅ начать карьеру в аналитике с нуля,
✅ перейти из других IT-специализаций (технические писатели, тестировщики, менеджеры проектов или специалисты, сотрудничающие с IT-отделами в компаниях) и освоить навыки сразу трёх профессий: системный аналитик, бизнес-аналитик и менеджер проектов.
👉 Также подойдёт действующим младшим системным аналитикам, которые хотят структурировать знания и получить новый уникальный опыт.
Перед обучением проводим вводное интервью, чтобы вы смогли разобраться подходит ли вам программа. Разберём текущую ситуацию, зададим вопросы и дадим рекомендации от эксперта.
Записаться на интервью и узнать подробности о курсе можно здесь.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤2❤🔥1