Skip to content

Latest commit

 

History

History
90 lines (77 loc) · 6.61 KB

04-workflow.md

File metadata and controls

90 lines (77 loc) · 6.61 KB

Ход сеанса синхронизации

Итак, приложению необходимо выполнить один из Сценариев синхронизации. Для этого необходимо выполнить определенные API запросы в определённом порядке.

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

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

Ниже приведён алгоритм выполнения API запросов для выполнения одного любого сценария синхронизации. Здесь "Готово" означает успешное завершение алгоритма, а "Отказ" означает завершение с ошибками.

  • (1) Основной API запрос согласно сценарию: запрос снапшота, запрос разницы или отправка изменений. Проверить код HTTP ответа.

    • (200) Только для запросов получения данных. Готовые данные взяты из кеша на сервере. В теле HTTP ответа содержится объект Cubux.Sync.Response с искомыми данными. Готово.
    • (202) Обработка поставлена в очередь. В теле ответа содержится объект Cubux.Sync.Response с тикетом T. Тикет используется далее.
    • (204) Только при запросе разницы. Изменений нет. Тело ответа пустое. Готово.
    • (304) Только для запросов получения данных с использованием HTTP кеширования. Изменений нет, данные в HTTP кеше клиента актуальны. Тело ответа пустое. Готово.
    • (410) Только при запросе разницы. Базовая ревизия слишком старая. Отказ — необходимо производить запрос снапшота вместо этого.
    • (422) Только при отправке изменений. Отправленный пакет отклонён, т.к. имеет ошибки по вине разработчика клиента. Отказ.
    • (4xx прочие) Отказ. Обработка согласно спецификации HTTP.
    • (5xx) Отказ. Обработка согласно спецификации HTTP.

  • (2) Ожидание завершения обработки тикета T. Ожидание возможно организовать любым из нижеперечисленных способов. Ошибочные HTTP статусы ответов на запрос тикета обрабатывать согласно спецификации HTTP.

    • (a) Выждать таймаут (лучше рандомный с долями секунд) около 1—3 секунд и выполнить запрос тикета. Ответ содержит объект Cubux.Sync.Response R, где содержится объект тикета (возможно, обновленный) T1. Проверить статус status тикета T1. Если тикет еще не завершен ("new", "work"), повторить этот пункт с ожидания.

    В любом случае, если ожидание затянулось на длительный срок (установленный ТЗ; например, порядка пары минут), — Отказ, необходимо повторить сеанс позже с начала.

  • (3) Проверить статус status тикета T1:

    • Если тикет завершен успешно ("done"), (при этом, если начальным запросом (1) был запрос данных, объект ответа R содержит искомые данные), то Готово.
    • Если тикет был отклонён ("aborted"), то Отказ. Объект тикета T1 содержит информацию об ошибках. Ошибки пользователя следует показать пользователю согласно ТЗ клиента. Ошибки разработчика рекомендуется так или иначе довести до сведения разработчика клиента.
    • Иначе ("failed") возникла ошибка при обработке тикета сервером. Отказ. Необходимо разбираться с техподдержкой API сервера. Возможно, начальный запрос (1) можно повторить позже без особых изменений.