Transcription
Сегодня мы разбираем просто сумасшедшее собеседование на роль системного аналитика. Герою этого ролика пришлось несладко. Спасибо, что я не на его месте. Я просто дам ответы на все вопросы, которые ему задавали, дабы сэкономить твоё время на прохождение реальных собеседований. За это лайк и подписка. Погнали.
Первый вопрос, который я спрашиваю на собеседовании - это роль системного аналитика. В чём она заключается?
Системная аналитика - это такой мостик между бизнесом и разработчиками. Его главная задача - перевести бизнес-требования, то есть что нужно заказчику, в понятный для программиста технический язык. Он как будто переводит с человеческого на технический. Он детализирует задачи, описывает, как система должна работать, чтобы все понимали, что именно Троица.
Хорошо. Чем тогда занимается бизнес-аналитик, например?
Бизнес-аналитик занимается тем, что выясняет, что нужно бизнесу. Он общается с заказчиками, изучает их процессы, чтобы понять, какую проблему нужно решить или какую выгоду получить. Он описывает это на бизнес-языке. А системный аналитик, получив это, что уже продумывает, как это реализовать технически. То есть он углубляется в детали системы, описывает логику её работы, взаимодействия, работу с данными.
А вот если мы говорим с тобой про требования, вот у нас есть два основных вида требований. А какие это?
Есть два основных вида требований: функциональные и нефункциональные. Функциональные требования описывают, что система должна делать. Например, система должна позволять пользователю регистрироваться. А нефункциональные требования описывают, как система должна работать: быстро, безопасно, надёжно. Например, система должна обрабатывать запрос за одну секунду.
Давай представим, что у нас есть такая кофеварка, какой-нибудь комбайн, как в Старбоксе стоит, такой вот большой электрический. Тебе нужно придумать к нему пример одного функционального и одного нефункционального требования.
Хорошо, давайте подумаем. Функциональное требование к кофеварки может быть таким: Кофеварка должна уметь заваривать эспрессо, то есть это действие, которое она выполняет. А нефункциональное требование: кофеварка должна приготовить эспрессо не более чем за 30 секунд после нажатия кнопки. Это уже про качество и скорость её работы.
Приходилось, может быть, я сталкивался в своей работе с бизнес-правилами?
Да, конечно, приходилось. Бизнес-правила - это своего рода инструкции или ограничения, которые диктуют бизнес. Они определяют, как компания ведёт свою деятельность. Например, если интернет-магазин говорит: "Бесплатная доставка" предоставляется только при заказе от 5.000 руб. Это бизнес-правила. Системный аналитик должен это учесть и реализовать в системе.
Можешь сказать, например, что такое пользовательские требования и чем они отличаются от бизнес-требований?
Если бизнес-требования - это высокоуровневые цели компании, например, увеличить продажи на 20%, они отвечают на вопрос: зачем нужна система? Пользовательские требования - это то, что обычно пользователь может делать системой, чтобы достичь этих бизнес-целей. Например, пользователь должен иметь возможность оформить заказ на сайте. Пользовательское требование детализирует бизнес-требования и описывают действия этого пользователя.
Мы, когда описываем порой требования, мы прибегаем к таким артефактам, как user story и use case. А можешь рассказать немного про эти артефакты?
User story или, как по-другому говорят, пользовательская история - это короткое и простое описание функционала с точки зрения конечного пользователя. Обычно пишется в формате: как роль пользователя, я хочу какое-то действие, чтобы получить какую-то выгоду. Например, как пользователь, я должен добавлять товар в корзину, чтобы потом оформить заказ. User case или вариант использования - это более подробное описание того, как пользователь взаимодействует с системой для достижения определённой цели. Он включает шаги, альтернативные сценарии, исключения. Это такой сценарий, который показывает полную последовательность действий.
Хорошо, давай на секунду вернёмся к user story. Тут упоминал, что есть критерии INVEST. А помнишь, как они расшифровываются?
Критерий INVEST - это набор рекомендаций для написания хороших пользовательских историй. INVEST шифровывается как: Independent, то есть независимое, и означает история должна быть самостоятельной и не зависеть от других историй. Negotiable, то есть обсуждаемые, детали истории можно и нужно обсуждать с командой. Valuable, то есть приносящее ценность, история должна приносить ценность пользователю или бизнесу. Estimable или по-другому оцениваемое, это значит, что команда должна уметь оценивать, сколько времени занимает её реализация. Small, то есть маленькая, история должна быть достаточно маленькой, чтобы её можно было реализовать за один спринт. Testable, то есть тестируемое, должно быть понятно, как проверить, что история реализована правильно.
Давай с тобой вспомним методы сбора требований. Ты общался с заказчиком. Какие методы сбора требований ты использовал?
Методов сбора требований достаточно много. Самые распространённые:
1. Интервью с заказчиками и ключевыми пользователями.
2. Проведение воркшопов и мозговых штурмов.
3. Наблюдение за работой пользователей.
4. Анализ существующей документации.
5. Анкетирование и опросы.
6. Создание прототипов или макетов системы.
7. Бенчмарк, то есть изучение решений конкурентов.
Сейчас поговорим с тобой про методы приоритизации требований, потому что, собственно, вот мы сейчас собрали требования там с помощью интервью, анкетирования или ещё чего-то. Список требований у нас появился определённый и достаточно он большой. Надо как-то приоритизировать. А знакомы может быть какие-то методы приоритизации требований?
Для приоритизации требований используют разные методы. Самые известные:
1. MoSCoW, то есть штука, которая делит требования на Must have, то есть обязательные, Should have желательные, Could have, можно, но не обязательно, и Won't have, то есть, которые не нужны.
2. Метод Kano. О нём мы чуть позже поговорим, но он классифицирует требования по степени удовлетворённости клиента.
3. RICE. Он оценивает требования по охвату (Reach), влиянию (Impact), уверенности (Confidence) и трудоёмкости (Effort).
4. WSJF, то есть Weighted Shortest Job First. Используется в agile методологиях. В нём приоритет отдаётся задачам, которые приносят наибольшую цену за короткий срок.
Может быть, приходилось слышать про матрицу Kano или MoSCoW. А теперь подробнее про модель Kano.
Модель Kano - это подход к приоритизации требований, основанный на том, как эти требования влияют на удовлетворённость клиента. Она делит функционал на несколько категорий:
1. Обязательное - это то, что клиент ожидает по умолчанию. И без этого продукт вообще даже не будет работать. Если этого нет, клиент очень недоволен.
2. Одномерные - чем больше этого функционала, тем больше удовлетворённость клиента.
3. Привлекательные - это то, что приятно удивляет клиента, чего он не ожидает, но что вызывает восторг.
4. Безразличные - фичи, которые не влияют на удовлетворённость клиента вообще никак.
5. Обратные - то есть фичи, которые вызывают недовольство, если они есть.
У нас есть ещё такой процесс, как валидация и верификация требований. Знаешь, что есть что?
Это два важных этапа проверки требований. Валидация - это проверка того, что мы строим правильный продукт. То есть соответствует ли он реальным потребностям заказчика и пользователей, отвечает на вопрос: построили ли мы то, что нужно? А верификация - это проверка того, что мы строим продукт правильно, то есть соответствует ли он заданным спецификациям и стандартам. Отвечает на вопрос: соответствует ли то, что мы строим, нашим планам?
Какие ты можешь выделить качества хорошего требования?
Итак, хорошее требование должно быть:
1. Однозначным, то есть его можно интерпретировать только одним способом.
2. Полным. Оно должно содержать полную необходимую информацию.
3. Непротиворечивым, то есть не должно конфликтовать с другими требованиями.
4. Тестируемым, то есть должна быть возможность проверить, что оно выполнено.
5. Атомарным, то есть описывать одну конкретную функциональность.
6. Измеримым, то есть оно должно иметь количественные характеристики.
7. Реализуемым, то есть должно быть технически возможно его реализовать.
8. Приоритизируемым, чтобы можно было определить его важность.
Чем мы BPMN используем? Что это такое?
BPMN расшифровывается как Business Process Model Notation. Это такой стандарт для графического описания бизнес-процесса. Мы используем BPMN, чтобы наглядно показать, как работает тот или иной процесс в компании, кто что делает и в какой последовательности, при каких условиях. Это помогает всем, и бизнесу, и разработчикам, лучше понять процесс и найти в нём узкие места и его улучшить.
Помнишь, какие элементы мы используем для построения модели BPMN?
В BPMN используется четыре основные группы элементов:
1. Объекты потока: это события (кружочки), действия (прямоугольники) и шлюзы (ромбы).
2. Соединяющие объекты: это потоки операции (обозначаются как стрелки и показывают последовательность), потоки сообщений (обозначаются как пунктирные стрелки и показывают обмен информацией).
3. Объекты данных: это входы, выходы данных, хранилища данных.
4. Дорожки: это некие пулы, которые представляют участника процесса (например, отдел или компанию), и дорожки внутри пулов, которые показывают роли или подразделения внутри этого участника.
Надеюсь, понятно объяснил. Смотри, если мы говорим про дорожки и пулы, вот у нас что во что входит? Дорожка в пул или пул в дорожку?
В BPMN дорожка (или по-другому "лейн") находится внутри пула. Пул - это как большой контейнер для всего процесса или для отдельного участника, например, целой компании. А дорожки внутри этого пула, они делят его на отдельные ответственности, например, отделы или роли: отдел продаж, отдел логистики и так далее.
Кроме начального и конечного события, может быть, есть какие-то ещё?
Кроме события начала и конца, которые просто обозначают стартовую, конечную точку процесса, есть ещё промежуточные события. Они могут быть привязаны к задаче или находиться в потоке. Например, это могут быть:
* Событие сообщения (когда что-то происходит из-за получения или отправки сообщений).
* Событие таймер (когда что-то срабатывает по времени).
* Событие ошибки (когда процесс реагирует на какую-то ошибку).
* И другие, например, событие эскалации, сигнала и компенсации.
Дорогой друг, если ты рассматриваешь возможность устроиться на работу системным аналитиком в кратчайшие сроки, то у меня для тебя кое-что есть. И это, конечно, обучающая программа "Офер под ключ". И мы не продаём вам какие-то курсы, мы помогаем получить офер и пройти испытательный срок. Всего 3-4 месяца, и мы устраиваем вас на позицию middle системным аналитиком с зарплатой от 150.000 руб. И это всё с гарантией. Под ключ. Проверено более 100 нашими выпускниками. Отзывы есть в нашем Telegram-канале. Более подробная информация и видео о программе вы можете увидеть на нашем сайте. В общем, переходи по ссылке в описании и оставляй заявку.
Ты упоминал событийный шлюз. Какие ещё шлюзы можешь назвать?
Кроме событийного шлюза, который позволяет выбрать путь в зависимости от того, какое событие произойдёт первым, есть и другие важные типы шлюза:
* Исключающий шлюз (обозначается ромбом с буквой X или просто пустым ромбом). Он выбирает только один из возможных путей.
* Параллельный шлюз (ромб с плюсом). Он выпускает все исходящие пути одновременно.
* Включающий шлюз (ромб с кружочком). Он может запускать только один или несколько путей в зависимости от условий.
* Также есть комплексный шлюз и другие, менее часто используемые.
Давай немножко поговорим про UML. Ну давай тогда, раз ты работал с диаграммой классов и с диаграммой последовательности, давай начнём с диаграмм последовательности.
Диаграмма последовательности или sequence diagram - это один из типов диаграмм в UML. UML расшифровывается как Unified Modeling Language или унифицированный язык моделирования. Диаграмма последовательности показывает, как объекты системы взаимодействуют друг с другом во времени. Она очень хорошо иллюстрирует порядок вызовов методов, обмена сообщениями и выполнения операций. Это помогает понять логику работы конкретной функции или сценария в системе. Например, как пользователь логинится или оформляет заказ.
Раз мы говорим про аутентификацию, вот вообще что за процесс такой аутентификация?
Это два разных, но связанных процесса в безопасности. Идентификация - это процесс определения, кто вы. Это когда вы говорите системе своё имя пользователя или ID. Система спрашивает: "Кто ты?". А аутентификация - это процесс подтверждения того, что вы действительно тот, за кого себя выдаёте. Это вы, когда вводите пароль или используете отпечаток пальца, система проверяет: "Докажи, что это ты".
Приходилось, может быть, сталкиваться с такой вещью, как "линия жизни" в диаграмме последовательности?
Линия жизни или lifeline в диаграмме последовательности - это вертикальная пунктирная линия, которая идёт вниз от каждого объекта или актора. Она показывает существование этого объекта во времени. А фокус управления или activation occurrence - это прямоугольник, который появляется на линии жизни. Он показывает период времени, когда объект активно выполняет какое-то действие или ждёт ответа. То есть когда объект включён или работает.
А если у нас линия жизни прерывается, как это выглядит на модели?
Если линия жизни прерывается, это означает, что объект прекращает своё существование в процессе взаимодействия. На диаграмме это обычно показывается крестиком (X) на конце линии жизни. После этого крестика пунктирная линия больше не продолжается. Это может быть, например, когда объект удаляется из памяти или сессия завершается.
Давай тогда вспомним про диаграмму классов. А вообще зачем диаграмма классов используется?
Диаграмма классов - это ещё один вид диаграмм UML. Она используется для того, чтобы показывать статическую структуру системы. То есть она отображает классы, их атрибуты, их методы и, самое главное, связи между этими классами. Это как чертёж дома, где показаны комнаты, их размеры и как они между собой соединены. Диаграмма классов помогает разработчикам понять, как будет организован код, как будут храниться данные и как объекты будут взаимодействовать друг с другом.
Помнишь, какие виды связей есть в диаграмме классов?
В диаграммах классов есть несколько важных видов связей:
1. Ассоциация. Это самая общая связь, и она просто показывает, что классы связаны.
2. Агрегация. Это тип ассоциации "часть-целое", когда часть может существовать отдельно от целого. Например, машина имеет двигатель, но двигатель может быть отдельно от машины.
3. Композиция. Это более строгий тип "часть-целое", когда часть не может существовать без целого. Например, дом имеет комнату, и комната не может существовать без дома.
4. Наследование или генерализация. Это связь по типу "является". Когда один класс наследует свойства и поведения другого. Например, автомобиль является транспортным средством.
5. Зависимость. Это когда изменение в одном классе может повлиять на другой, но не всегда напрямую.
А как мы вообще реализуем связь "многие ко многим"?
Связь "многие ко многим" между двумя сущностями (например, студенты и курсы, то есть один студент может изучать много курсов, и один курс может быть изучаемым большим количеством студентов) реализуется через создание дополнительной, так называемой промежуточной или ассоциативной таблицы в базе данных. Эта таблица будет содержать первичные ключи от обеих связанных таблиц, по сути, связывая их записи.
Может быть, слышал про наследование, агрегацию?
На этот вопрос мы уже отвечали, но повторение - мать учения, поэтому давайте повторим. Наследование - это когда один класс-потомок принимает свойства и поведение другого класса-родителя. Это отношение по типу "является". Например, собака является животным, собака наследует характеристики животного. А агрегация - это тип отношений "часть-целое". Она показывает, что класс является частью другого, но может существовать отдельно. Например, автомобиль содержит колесо. Колесо - это часть автомобиля, но оно может быть и просто колесом, не привязанным к конкретной машине. Это слабая связь.
Какие у нас есть два основных вида баз данных?
У нас есть два основных вида баз данных: реляционные и нереляционные.
* Реляционные базы данных или SQL-базы данных хранят данные в виде таблиц, которые связаны между собой. Их основные особенности:
1. Данные организованы в строки и столбцы, как в Excel.
2. Связь между таблицами устанавливается с помощью ключей (первичных и внешних).
3. Поддерживают ACID-свойства (атомарность, согласованность, изолированность и надёжность), что гарантирует целостность данных.
4. Для работы с ними используется язык SQL.
* Нереляционные базы данных (NoSQL) имеют другие структуры хранения.
Помнишь ли виды ограничений в реляционных базах данных?
Ещё constraints ещё иногда называют. В реляционных базах данных есть ограничения или constraints, которые обеспечивают целостность и корректность данных. Вот основные из них:
1. Primary Key (первичный ключ) - уникальный идентификатор каждой записи в таблице.
2. Foreign Key (внешний ключ) - связывает таблицы, ссылаясь на первичный ключ в другой таблице.
3. Unique (уникальный) - гарантирует, что все значения в столбце уникальны, но может быть, например, NULL.
4. Not NULL (не пустое) - запрещает NULL-значение в столбце.
5. Check (проверка) - устанавливает условие, которое должно быть истинным для каждого значения в столбце. Например, возраст больше 18.
6. Default - устанавливает значение по умолчанию, если оно не указано.
Каково же понятие нормализации базы данных?
Нормализация в базе данных - это процесс организации таблиц и колонок таким образом, чтобы уменьшить избыточность данных и улучшить их целостность. По сути, мы разбиваем одну большую таблицу на несколько маленьких, связанных между собой, чтобы избежать дублирования информации. Например, вместо того, чтобы хранить полное имя и адрес клиента в каждой строке заказа, мы создаём отдельную таблицу клиента и ссылаемся на неё по ID.
А до какой нормальной формы надо дойти, чтобы считалась база данных, ну, нормальной?
Как бы для большинства обычных транзакционных систем, где важна запись и целостность данных, достаточно достичь третьей нормальной формы или 3NF. Это считается хорошим бейзлайном между уменьшением избыточности и сложностью структур. Бывают и более высокие формы, но они используются реже.
Ты говорил про процесс над денормализацией. А вообще зачем мы можем денормализовывать базу данных? С какой целью?
Денормализация - это обратный процесс нормализации, когда мы сознательно добавляем избыточные данные в таблицы. Мы это делаем в основном для одной цели: чтобы увеличить скорость чтения данных. В сложных запросах, например, для отчётов или аналитики, где нужно объединять много таблиц, денормализация позволяет получать все нужные данные из одной или нескольких таблиц быстрее, избегая множество джоинов. Часто это используется в Data Warehouse, то есть хранилищах данных для аналитики.
Приходилось, может быть, встречаться с DWH или Data Lake?
DWH расшифровывается как Data Warehouse или хранилище данных. Это такие централизованные хранилища, где собраны очищенные и структурированные данные из различных источников для целей анализа или, например, отчётности. Данные здесь уже готовы к использованию. А Data Lake или озеро данных - это более новый подход. Это огромное хранилище для сырых, неструктурированных данных в их оригинальном формате. Данные сюда просто скидывают и структурируют только тогда, когда это нужно для конкретной аналитической задачи. Лично я сталкивался с концепциями DWH в нескольких проектах, где мы готовили данные для отчётности.
Встречалось такое понятие, как шардирование, может быть, репликация?
Шардирование и репликация - это две техники для масштабирования баз данных.
* Шардирование или горизонтальное масштабирование - это когда мы делим большую базу данных на несколько более маленьких частей, называемых шардами, и размещаем их на различных серверах. Например, одна часть данных хранится на одном сервере, другая - на другом. Это помогает обрабатывать больше запросов и хранить больше данных.
* Репликация - это процесс создания нескольких точных копий базы данных, где одна копия является мастером (то есть главной), а остальные - репликами. Если мастер-сервер выходит из строя, одна из реплик может взять на себя его роль. Это повышает отказоустойчивость и позволяет распределять нагрузку по чтению между репликами.
Какие виды архитектур тебе знакомы?
Помимо традиционной монолитной архитектуры, где весь код приложения находится в одном блоке, мне также знакомы и другие подходы:
1. Микросервисная архитектура, когда приложение разбивается на множество маленьких независимых серверов, каждый из которых выполняет свою конкретную функцию.
2. Сервисно-ориентированная архитектура, сокращённо SOA. Она похожа на микросервисы, но сервисы здесь крупнее и могут быть построены на различных технологиях. Взаимодействуют они через шину сообщений или сокращённо ESB.
3. Событийно-ориентированная архитектура EDA, то есть система построена вокруг событий, а компоненты реагируют на эти события.
4. Бессерверная архитектура, где разработчики пишут код, а облачный провайдер берёт на себя управление сервером. Это не значит, что серверов нет, просто ими управляет не разработчик.
А какие можешь выделить плюсы и минусы в микросервисах?
Микросервисы имеют пять основных плюсов, особенно для больших и сложных систем:
1. Независимое развёртывание. То есть каждый сервис можно развёртывать, обновлять, откатывать независимо от других.
2. Масштабируемость. Можно масштабировать только те части системы, которые действительно нуждаются в большей мощности.
3. Отказоустойчивость. То есть один из сервисов падает, а остальные продолжают работать.
4. Гибкость в технологиях. То есть для каждого сервиса можно выбрать свою технологию, язык программирования, базу данных, если это, конечно же, оправдано.
5. Автономия команд. То есть каждая команда может отвечать за свой конкретный сервис, и это ускоряет работу. Не нужно вникать каждой команде в различные сервисы, достаточно одного сервиса, достаточно одной команды.
Ну ты упоминал принцип оркестрации. А помимо оркестрации что-то у нас ещё есть? Может быть?
Помимо оркестрации есть хореография. Эти два подхода к управлению взаимодействием между микросервисами.
* При оркестрации есть центральный оркестратор, который, как дирижёр, говорит каждому сервису, что и когда делать, и также он управляет всей последовательностью операций.
* При хореографии нет центрального координатора. Каждый сервис сам реагирует на события, которые приходят в системе, и выполняет свои действия. Сервисы же общаются между собой через события, не зная о других сервисах напрямую. Хореография более децентрализованная и гибкая, но сложнее гораздо для отладки.
С паттерном Saga не приходилось сталкиваться?
Паттерн Saga - это способ управления распределёнными транзакциями в микросервисной архитектуре, чтобы обеспечить согласованность данных. Поскольку в микросервисах у каждого сервиса есть своя база данных, нельзя использовать обычные транзакции. Saga - это последовательность локальных транзакций, выполняемых разными сервисами. Если какая-то часть Saga не удалась, то выполняются компенсационные операции, которые отменяют изменения, сделанные предыдущими шагами. Например, при оформлении заказа сначала бронируется товар, потом списываются деньги, потом формируется доставка. И если оплата не прошла, то товар просто разбронируется.
Допустим, у нас надо объединить несколько микросервисов между собой. А какими способами можно это сделать?
Микросервисы могут связываться друг с другом разными способами. Самые частые из них:
1. REST API. Это когда сервис вызывает другой по HTTP-протоколу, отправляя и получая различные данные.
2. Брокер сообщений или по-другому Message Queue. Это когда сервисы обмениваются сообщениями через промежуточную очередь. Это позволяет асинхронно обрабатывать данные и повышает отказоустойчивость.
3. gRPC. Это высокопроизводительный фреймворк для удалённых вызовов процедур, часто используется для внутренней коммуникации.
4. GraphQL. Он позволяет клиенту запрашивать именно те данные, которые ему нужны, сокращая количество запросов.
Смотри, вот если смотреть, так скажем, свысока, вот как будто бы брокер сообщений и шина данных очень похожи, потому что, ну, вот все микросервисы через общаются либо через брокер, либо через шину, и, ну, такая паутина получается, условно говоря. Все участники, они в одном каком-то таком буфере общаются. А вот почему всё-таки всё равно это два разных вида интеграции?
Корпоративная шина или по-другому ESB (Enterprise Service Bus) и брокер сообщений - это оба инструмента для интеграции систем, но они отличаются по функционалу и сложности.
* Брокер сообщений - это относительно простой инструмент. Его основная задача - доставлять сообщения от одного сервиса к другому, обеспечивая асинхронную связь. По сути, это такая "глупая труба", которая просто пересылает данные. Например, RabbitMQ или Apache Kafka.
* Корпоративная шина или по-другому ESB - это более сложная система. И помимо доставки обычных сообщений, она выполняет трансформацию данных, то есть маршрутизацию сообщений по сложным правилам, оркестрацию процессов, конвертацию протоколов. Короче, ESB - это такая "умная труба", которая не просто передаёт, но и обрабатывает сообщения. Она централизована и часто используется для интеграции большого количества разнородных систем.
Знаешь, ну есть принцип Push и есть принцип Pull-модели. Вот RabbitMQ и Kafka, они к каким относятся?
Это две модели получения сообщений из брокера.
* Push-модель: брокер сообщений сам "толкает" сообщения потребителям, как только они появляются. А потребитель не должен постоянно спрашивать, есть ли новые сообщения. К этой модели относится, например, RabbitMQ.
* Pull-модель: потребитель сам "тянет" сообщения из брокера, когда он готов их обрабатывать. Он сам запрашивает сообщения. К этой модели, например, относится Kafka.
Да, мы общаемся по HTTP методам в REST. А какие методы ты знаешь?
Основные методы или ещё их называть глаголами, которые используются в REST API для работы с ресурсами:
* GET - для получения данных.
* POST - для создания какого-то нового ресурса.
* PUT - для полного обновления существующего ресурса или создания нового, если его нет.
* DELETE - для удаления ресурса.
* PATCH - для частичного обновления ресурса.
Чем у нас POST от PUT отличается?
Ключевое отличие, конечно, в их назначении и идемпотентности.
* POST используется для создания нового ресурса. Каждый раз, когда вы делаете POST-запрос, скорее всего, создаётся новый ресурс, поэтому он не идемпотентен.
* PUT используется для полного обновления существующего текущего ресурса. Если ресурс не существует, PUT может его создать. Это называется upsert. И вот метод PUT, он идемпотентен. Это означает, что многократное выполнение его приведёт к одному и тому же результату. То есть новые ресурсы не будут создаваться, если вы много раз выполните метод PUT.
На каком понятие идемпотентности методов?
Идемпотентность - это свойство операции, обозначающее, что её многократное выполнение приводит к такому же результату, что и однократное. То есть, если вы отправите один и тот же идемпотентный запрос 10 раз, состояние системы после всех этих запросов будет точно таким же, как если бы вы отправили его только один раз. Это очень важно для надёжности API, так как позволяет безопасно повторять запросы, например, в случае сбоя сети.
Хорошо. А какие методы у нас неидемпотентные?
Чаще всего неидемпотентным методом в REST API считается POST, потому что каждый раз, когда вы отправляете POST-запрос с одними и теми же данными, скорее всего, будет создан новый ресурс. Например, отправляя POST-запросы на создание нового заказа, вы будете каждый раз создавать новый заказ, а не изменять существующий.
Помнишь принципы REST?
У REST есть шесть ключевых принципов, которые делают его таким эффективным:
1. Клиент-серверная архитектура. То есть клиент и сервер разделены, они не знают внутренней реализации друг друга.
2. Отсутствие состояний. То есть сервер не хранит информацию о предыдущих запросах клиента. Каждый запрос должен содержать всю необходимую информацию для операций.
3. Кэшируемость. То есть клиенты могут кэшировать ответы сервера, чтобы улучшить производительность.
4. Единообразный интерфейс. То есть самый важный принцип. Он означает, что API должен быть понятен и прост в использовании, а его ресурсы должны быть доступны по уникальным URI (Uniform Resource Identifier), кто не знал, как это переводится. И для работы с ними используются стандартные HTTP-методы.
5. Многоуровневая система. Это означает, что клиент может не знать, общается ли он напрямую с сервером или через какие-то промежуточные слои (прокси, балансировщики и так далее).
6. Код по запросу. Этот принцип является, на самом деле, опциональным, и он позволяет серверу отправлять исполняемый код клиенту, чтобы расширить его функциональность.
Помнишь, что такое принцип Webhook?
Принцип работы Webhook очень простой. Это механизм, который позволяет одному приложению автоматически уведомлять другое приложение о наступлении какого-либо события. Вместо того, чтобы одно приложение постоянно спрашивало другое о том, не произошло ли что-то новое (это, кстати, называется пулинг), Webhook работает наоборот: когда события происходят, первое приложение само отправляет HTTP-запрос на заранее заданный URL второго приложения. То есть это в неком смысле такой обратный звонок. Например, когда кто-то оплатил заказ на сайте, платёжная система может отправить Webhook к вашему серверу, чтобы сообщить об этом.
Фух, ребят, надеюсь, вы кайфанули от того объёма информации, который сейчас получили. А главное того, что вместо откликов на hh.ru и дальнейшего собеса с HR, прохождения технического собеседования, вы просто посмотрели это короткое видео и что-то для себя усвоили. Учти, что даже просто смотря мои собеседования, можно научиться их проходить. Поэтому с тебя лайк и подписка. А если ты хочешь больше контента, связанного с трудоустройством в IT, и быть в курсе последних изменений на рынке труда в IT, подписывайся на мой Telegram-канал. Надеюсь, после выхода этого ролика его не закроют. Ну и, конечно же, записывайся на нашу обучающую программу "Офер под ключ", чтобы получить офер за пару месяцев. Желаю всех жирных оферов и спелых арбузов.