Какие запросы отправляются при работе с календарем?

Что проверяют

Умеете ли вы разложить знакомую функцию на запросы к API и понять, что проверять в каждом. Часто это практика: открыть DevTools на странице календаря и рассказать, что уходит при создании встречи. Следом спрашивают про часовые пояса и повторяющиеся события.

Как отвечать

Идите от действий пользователя к HTTP-методам:

• просмотр: GET списка событий за период с параметрами начала и конца диапазона, GET одного события по идентификатору;
• создание: POST с JSON-телом: название, начало и конец с часовым поясом, участники, напоминания. В ответ 201 Created или 200 с созданным объектом;
• изменение: PATCH для частичного обновления (перенесли время) или PUT для полной замены;
• удаление: DELETE, обычно с ответом 204 No Content;
• служебные: проверка занятости участников, отправка приглашений и ответ на них, синхронизация изменений с момента прошлого запроса.

Покажите знание предметной области. Время передают в ISO 8601 со смещением или в UTC плюс отдельное поле часового пояса. Повторяющиеся события описывают правилом RRULE из стандарта iCalendar (RFC 5545), и изменение одного вхождения серии создаёт исключение, а не новую серию.

Проверки стройте вокруг рисков: событие через полночь и через переход на летнее время, участник в другом поясе, конец раньше начала (ждёте 400), чужое событие без прав (403), несуществующее (404), одновременная правка двумя пользователями. Инструменты: вкладка Network в DevTools, Postman для ручных проверок, для автотестов REST Assured или pytest с requests.

Где спотыкаются

Перечисляют GET, POST, PUT, DELETE и останавливаются. Интервьюер ждёт привязки к календарю: диапазоны, часовые пояса, повторения.

Забывают про PATCH и не могут объяснить, чем он отличается от PUT при переносе встречи.

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