Проектирование интерфейса страницы бронирования отеля

Условие

Представьте, что экран бронирования, аналогичный показанному на скриншоте, ещё не реализован. Требуется:

• Выявить набор UI‑компонентов, которые необходимо создать на клиентской части.
• Сформировать список контрактов (REST‑эндпоинты, поля запросов/ответов, форматы данных), которые следует согласовать с бек‑эндом.
• Определить, какие данные будут получаться от сервера, а какие – отправляться обратно.
• Учесть взаимодействие с элементами оплаты, механизмами скидок, промокодами, бонусными начислениями и формами ввода данных гостей.
• Принять во внимание адаптивную верстку и пользовательский опыт: валидацию полей, состояния загрузки, обработку ошибок.
• Описать подход к началу разработки в условиях отсутствия готового API (мок‑серверы, заглушки, фиктивные ответы и т.п.).

Ответ

Разделите экран на условия проживания, гостей, стоимость, скидки и оплату. Согласуйте серверную котировку с версией и сроком действия; итоговую сумму не вычисляйте доверенно на клиенте.

Без самого скриншота можно предложить базовый контракт: GET данных отеля/доступности; POST котировки с room_id, датами, гостями и промокодом; POST бронирования с quote_id, контактами и ключом идемпотентности; отдельная инициализация оплаты. Сервер возвращает разбивку стоимости, валюту, доступные бонусы, ошибки полей и статус. Цена и наличие перепроверяются при подтверждении; карточные данные обрабатывает платёжный провайдер. Начните с согласованной схемы и mock-ответов для успеха, истёкшей цены, занятых номеров и ошибок. Предусмотрите мобильную компоновку, доступные формы, загрузку и безопасный повтор без дубля брони.