В IT все разборки только по-взрослому 😅

Как GitHub перешёл с REST на GraphQL и что из этого получилось?👆

Рассказываю в аудио классный случай из практики!

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

🎧Слушайте подкаст @openstudyit

Есть интересная задача по проектированию API + ПОДАРОК для вас🎁

Выбор оптимального API для обновления данных пользователя

Представьте, вы работаете над REST API для приложения управления пользователями. Вам нужно спроектировать конечную точку (endpoint) для обновления информации о пользователе по его уникальному идентификатору (user_id).

❗️Требования:
✔️Обновление данных пользователя должно быть частичным: клиент может отправить только те поля, которые нужно изменить

✔️Необходимо придерживаться RESTful стиля и использовать правильные HTTP методы

✔️Сервер должен обрабатывать запросы безопасно и эффективно

У вас есть три варианта реализации:
1️⃣ HTTP метод: PUT
URL: /users/{user_id}
Тело запроса:
{
"name": "New Name"
}

2️⃣ HTTP метод: PATCH
URL: /users/{user_id}
Тело запроса:
{
"name": "New Name"
}

3️⃣ HTTP метод: POST
URL: /updateUser
Тело запроса:
{
"user_id": 123,
"name": "New Name"
}

Какой из вариантов является наиболее правильным с точки зрения RESTful практик для частичного обновления данных пользователя и ПОЧЕМУ?

Пишите вариант, который считаете верным, в комментариях и почему👇

Первые 5 подписчиков, кто ответит верно - получат крутой подарок от нас🎁

Да, это был метод PATCH для частичного обновления🔥

Почему? (здесь найдете вопрос)👇

Метод PATCH предназначен специально для частичного обновления ресурса.

✔️Клиент может отправить только те поля, которые нужно изменить, без необходимости предоставлять полное представление ресурса.

✔️ Это соответствует требованию о частичном обновлении данных пользователя.

RESTful URL:

☑️ URL /users/{user_id} правильно идентифицирует ресурс пользователя по его уникальному идентификатору.

☑️ Это соответствует RESTful практике использования путей для обращения к ресурсам.

Часто используете этот метод в интеграции?

Patch это понятно)
А можете рассказать другое пожалуйста, почему в данной формулировке и вводных put не походит как ответ в вашем понимании?
Я на чем хочу сконцентрировать внимание:
То что вы не сказали какая метамодель у обьекта user. Если он у вас состоит из только имени и id (который передается в url). То put тут тоже работает.

Да ,действительно, если бы модель юзера состояла из больших атрибутов - то однозначный ответ в этом кейсе был бы Patch.

Я ошибаюсь?

Отличный вопрос - классная обратная связь от подписчика👆

Давайте разберёмся, почему в этом случае лучше использовать PATCH, а не PUT, даже если у нас у пользователя только id и name.

❗️Повторим разницу между PATCH и PUT

☑️ PUT:

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

☑️ PATCH:

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

Почему в нашем случае PUT может не подходить?

1️⃣ Риск потери данных

Если используешь PUT и отправляешь только name, не указывая другие поля, сервер может подумать, что ты хочешь заменить весь ресурс новым, который содержит только name.
Остальные поля могут быть удалены или сброшены, что приведёт к потере данных.

2️⃣ Соответствие стандартам (на них всё же опираются некоторые разработчики 😁)

По стандартам HTTP PUT должен использоваться для полной замены ресурса.
Использовать PUT для частичного обновления — это нарушение этих принципов и может привести к непредсказуемому поведению.

3️⃣ Будущие изменения

Сейчас у пользователя только id и name, но позже могут добавиться другие поля (например, email, age).
Если с самого начала используешь PUT для частичного обновления, потом придётся менять логику на клиенте, чтобы отправлять все поля, иначе новые могут быть потеряны.

Пример проблемы с PUT на пальцах👇

Представьте, что сейчас такая модель пользователя:
{
"id": 123,
"name": "Alice"
}

Вы отправляете запрос:
PUT /users/123
Content-Type: application/json

{
"name": "Bob"
}

Ожидаемый результат:
Изменится только name, остальные поля останутся.

Фактический возможный результат:
Сервер заменяет ресурс новым, где только name указано.
Получаем:
{
"id": null, // или id удаляется
"name": "Bob"
}
...Поле id потеряно, что плохо.


РЕЗЮМЕ

Подписчик прав, что в очень простом случае, когда у пользователя только id и name, использование PUT может показаться нормальным.

НО❗️
С точки зрения стандартов и будущего развития вашего API, PATCH — возможно более оптимальный выбор.

Это обеспечит безопасность данных и устойчивость API к изменениям.

Согласны?

Визуализация - зачем интеграция API😅

Коллеги, не сдерживайтесь в комментариях))

Курс для джунов? Или навыки API для более опытных ребят?

Подходит ВСЕМ - в видео пояснил, почему👆

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

1️⃣ основы по работе интернета

2️⃣ база по API (как, зачем, и почему)

3️⃣ проектирование API (REST, SOAP, и другие стили)

4️⃣ интеграция через брокеры сообщений - RabbitMQ и Kafka

5️⃣ алгоритм проектирования (паттерны, OpenAPI, документация и т.д.)

6️⃣ создание распределенных систем (микросервисы)

7️⃣ построение карьерного трека (составление резюме, подготовка к собеседованию)

Практики много, но домашки несложные, честно😉

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

После обучения наши ученики становятся на уровень middle специалиста😎

Вдруг кто забыл) У нас есть классный БОТ, где вы можете пройти БЕСПЛАТНЫЕ УРОКИ и протестировать начинку курса сами👍