​​📑 Аутентификация в веб-API: пример и ликбез по Postman

Автор Анна Вичугова
"Аналитики часто путают понятия аутентификации и авторизации, которые действительно связаны между собой, но отличаются. Чтобы подчеркнуть эту разницу, сегодня я на практическом примере интернет-магазина расскажу про HTTP-ответы и виды аутентификации веб-API, доступные в Postman."

Читать статью

#api #postman | @notes_analyst

​​Алоха, друзья! Сегодня мы поговорим о двух парнях - SOAP 🙋🏻и REST 🙋🏼‍♂️. Постараюсь рассказать простыми словами о них, чтобы было всем понятно, кто же эти парни))

👉🏻SOAP - мужик, который любит все делать в порядке. Он очень правильный и точный, всегда следует стандартам и правилам. Это тот чел, который всю жизнь работал в банке и никогда не опаздывал на работу. SOAP использует подход "запрос-ответ", что означает, что если вы что-то запросили, то вам обязательно придет ответ. SOAP считает, что порядок и правильность - это главное. Но, конечно, это может занять некоторое время.

👉🏻 А вот REST - это совсем другой тип. Он далек от стандартов и может быть очень неформальным. Это парень, который любит свободу и самостоятельность, он не любит ограничений и правил. REST использует подход "совместное использование ресурсов", что означает, что данные хранятся в одном месте и могут быть получены множеством клиентов одновременно. REST всегда готов к действию, главное - быстро и качественно.

Итак, какое же отличие между этими двумя парнями; спросите вы?
- SOAP может быть довольно медленным, потому что он всегда следует стандартам и держится правил, но все же он очень аккуратный.
- REST же быстр и готов к действию, он не признает границ и может работать с многими клиентами одновременно.

Теперь вы знаете, кто такие SOAP и REST, и какое отличие между ними. Выбирать между ними зависит от вашего личного вкуса и нужд. Если вам нужна точность и аккуратность - выбирайте SOAP, если же вам нужна свобода и быстрота - выбирайте REST. Но никогда не забывайте о том, что главное - это правильно подобрать того парня, который вам более подходит.

Источник: @ba_and_sa
#API #REST #SOAP

📎Ну а для углубления в тему предлагаю вам несколько статей:
- Применение SOAP при интеграции систем
- Everything about SOAP, REST, and Message Brokers


Всем удачи в выборе своего SOAP или REST!

Алоха! Добавила на канал теги для удобного поиска моих постов с разными рубриками (они будут обновляться и добавляться):

📌#профлитература
📌#вопросыссобеседования
📌#моделированиеПО
📌#программы #сервисы
📌#сбортребований
📌#api #rest #soap #интеграция
📌#жизненныйцикл
📌#дорожнаякарта
📌#БД #базыданных
📌#случайизжизни
📌#карьерныйпуть
📌#вопросотподписчика
📌#расширяемкругозор
📌#развитие
📌#повышениеквалификации

​​Алоха! Сегодня мы поговорим о двух новых парнях - gRPC 💁🏼и GraphQL 🙋🏻. Постараюсь рассказать простыми словами о них, чтобы было всем понятно, кто же эти парни))

👉🏻gRPC - дружелюбный парень, который способен передавать множество данных в режиме реального времени. Он использует протокол HTTP/2 и предоставляет высокоскоростной способ передачи данных между различными приложениями. Кроме того, он использует бинарный формат protobuf, что дает огромное преимущество в скорости передачи данных. Если приводить пример, то с помощью gRPC мы можем создавать микросервисы и между ними общаться в режиме реального времени. Хочешь обновить какие-то данные в одном сервисе и чтобы они автоматически обновились в другом сервисе? Без проблем, gRPC об этом позаботится.

👉🏻 А вот GraphQL - это совсем другой тип. Это серьезный мужик, который не бросает слов на ветер. Что у него просят, то от него и получают, т.е. он позволяет клиентам получать именно те данные, которые им нужны, а серверам возвращать только запрошенные данные и все это делает за один запрос, не то что его брат REST, который работает с несколькими запросами)

Как же выбрать, какой парень вам подходит больше? В зависимости от того, что вы хотите создать, один может быть лучше, чем другой. Если у вас микросервисная архитектура, то gRPC может быть выбором номер один, когда вам необходимо передавать много данных между сервисами. Если нет, то GraphQL - возможно, более подходящий вариант, поскольку его режим запроса-ответа позволяет клиентам запрашивать данные только тогда, когда это необходимо.

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

Источник: @ba_and_sa
#API

Пост про Сравнение REST и SOAP

📎Ну а для углубления в тему предлагаю вам несколько статей:
- Сравнение архитектурных стилей API: SOAP vs REST vs GraphQL vs RPC
- Сравниваем REST, GraphQL и gRPC
- REST vs SOAP, gRPC и GraphQL: стили межсистемной интеграции по API

Всем удачи в выборе своего gRPC или GraphQL!

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

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

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

Важными аспектами при документировании API являются:

✍🏼1. Описание ресурсов и методов: Документация должна содержать описание всех доступных ресурсов и методов, которые поддерживает API. Каждый ресурс должен быть подробно описан, включая его структуру данных, список полей, доступные методы и возможные запросы/ответы.

📌2. Примеры использования: Хорошая документация должна содержать множество примеров использования API. Примеры помогут разработчикам быстрее разобраться в функциональности и особенностях API, а также позволят им быстрее начать пользоваться им.

🌐3. Схемы данных: Для каждого ресурса API должны быть предоставлены схемы данных, описывающие структуру объектов, передаваемых по API. Схемы данных могут использоваться в процессе валидации запросов и ответов, а также для генерации моделей данных в клиентском коде.

😨4. Ошибки и исключения: Документация должна содержать список возможных ошибок и исключений, которые могут возникнуть при работе с API. Каждая ошибка должна быть подробно описана, включая информацию о причинах ее возникновения и возможные способы ее решения.

🔢5. Версионность: Важным аспектом документации API является указание версии API, чтобы разработчики могли быть уверены, что они используют актуальную версию. Необходимо предоставлять возможность переключения на более новые версии, сохраняя обратную совместимость с предыдущими версиями.

⏱6. Частые обновления: Документация API должна быть актуальной и регулярно обновляться с выпуском новых функций и исправлениями. Это поможет снизить степень путаницы у разработчиков и повысит удовлетворенность пользователей API.

📑7. Интерактивная документация: Для удобства использования API стоит предусмотреть возможность создания интерактивной документации, где разработчики могут отправлять запросы и видеть результаты в реальном времени, а также иметь возможность пробовать различные последовательности запросов.

Правильное документирование API является важным шагом для обеспечения успешной интеграции и сотрудничества с другими системами. Четкая, полная и понятная документация может значительно упростить жизнь разработчикам и сэкономить время и усилия при работе с API.

Источник: @ba_and_sa
#api #интеграция

Материалы по теме:
- Документирование API
- Что такое API документация и как ее правильно составить и использовать?
- How to Write Good API Documentation