Обзор коммуникации

Обновление передача является совместным усилием между устройством пользователя, серверами Apple и Вашими серверами. На высоком уровне это состоит из следующих шагов, показанных на рисунке 4-1:

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

2. Некоторое изменение инициировало обновление, и Ваш сервер отправляет уведомление нажатия.

3. Устройство пользователя получает уведомление, и это запрашивает Ваш сервер для получения списка изменений.

4. Устройство пользователя просит у Вашего сервера последнюю версию каждой изменившейся передачи.

Процесс обновления использует следующие данные:

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

URL веб-сервиса говорит Сберкнижку, как связаться с Вашим сервером во время процесса обновления. Это должно включать протокол, и это может включать дополнительный номер порта. Сберкнижка требует Подключения HTTPS к Вашему серверу для всей коммуникации. Во время разработки можно использовать настройки разработчика для разрешения простых HTTP-соединений.

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

Идентификатор библиотеки устройства является Специфичным для сберкнижки совместно используемым секретом между устройством пользователя и Вашим веб-сервером. Это не связано с идентификатором устройства (UDID). Устройство идентифицирует себя с различным ID к различным серверам, и оно может изменить свой ID в любое время. Его цель состоит в том, чтобы позволить эффективную коммуникацию между устройством и Вашим сервером, чтобы не позволить Вашему серверу сохранить список того, какие передачи в настоящее время устанавливаются на устройстве. Идентификатор библиотеки устройства однозначно определяет устройство и указывает, что объект, обращающийся с просьбой, разрешен выполнить такой запрос.

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

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

Таблица Devices

Устройство идентифицируется его идентификатором библиотеки устройства; это также имеет маркер нажатия.

Таблица Passes

Передача идентифицируется идентификатором типа передачи и порядковым номером. Эта таблица включает тег последнего обновления (такой как метка времени) для того, когда передача обновилась, и обычно включает любые данные, необходимо генерировать фактическую передачу.

Таблица Registrations

Регистрация является отношением между устройством и передачей. Необходимо быть в состоянии искать информацию в обоих направлениях: найти передачи, которые данное устройство зарегистрировало для, и найти устройства, зарегистрировавшиеся для данной передачи. Регистрация является many-many отношением: единое устройство может зарегистрироваться для обновлений к многократным передачам, и единственная передача может быть зарегистрирована многократными устройствами.

Регистр устройств для обновлений

После установки передачи устройство на iOS регистрируется в Вашем сервере, прося получать обновления. Ваш сервер спасает библиотеку ID устройства и ее маркер нажатия.

Устройство отправляет следующие данные:

• Идентификатор библиотеки Device (в URL)

• Продвиньте маркер (в полезной нагрузке JSON)

• Передайте идентификатор типа (в URL)

• Порядковый номер (в URL)

• Аутентификационный маркер (в заголовке)

Для обработки регистрации устройств сделайте следующее:

1. Проверьте, что аутентификационный маркер корректен. Если это не соответствует, сразу возвратите состояние HTTP 401 Несанкционированный и игнорируйте запрос.

2. Сохраните отображение между идентификатором библиотеки устройства и маркером нажатия в таблице устройств.

3. Сохраните отображение между передачей (идентификатором типа передачи и порядковым номером) и идентификатор библиотеки устройства в регистрационной таблице.

Когда устройство удаляет регистрацию, оно использует ту же конечную точку и отправляет те же данные. Различие - то, что устройство отправляет запрос DELETE вместо запроса POST, и Ваш сервер удаляет (или лишает законной силы), данные от его таблиц вместо того, чтобы добавить его. Когда устройство удаляет регистрацию, можно сразу удалить запись из регистрационной таблицы. Когда нет никаких записей для устройства в регистрационной таблице, можно удалить запись для устройства от таблицы устройств.

Ваш сервер отправляет уведомление нажатия, когда что-то изменяется

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

Ваш сервер отправляет следующие данные:

• Идентификатор типа передачи (в сертификате)

• Маркер нажатия (в коммуникации к службе Apple Push Notification)

Для отправки уведомления нажатия сделайте следующее:

1. Обновите таблицу передач с новой информацией о передаче и получите идентификатор типа передачи и порядковый номер для изменившейся передачи.

2. Консультируйтесь с регистрационной таблицей и получите список устройств, зарегистрировавшихся для обновлений для той передачи.

3. Консультируйтесь с таблицей устройств и получите маркер нажатия для каждого устройства.

4. Отправьте уведомление нажатия с пустым словарем JSON как его полезная нагрузка к каждому маркеру нажатия.

Можно задаться вопросом, почему сервер не включает больше информации в уведомление нажатия. Причина является двукратной: уведомления нажатия, как гарантируют, не будут поставлены, и многократные уведомления нажатия из того же источника объединяются в единственное уведомление. Если бы больше информации было включено, то она могла бы быть потеряна. Уведомление нажатия просто указывает, что некоторые передачи с данным идентификатором типа передачи изменились, таким образом, никакая информация не потеряна, если они объединяются.

Вы используете тот же сертификат и закрытый ключ для отправки уведомлений нажатия что касается подписания передач. Для получения дополнительной информации об уведомлениях нажатия, см. Локальное и Удаленное Руководство по программированию Уведомления.

Устройства просят измененные порядковые номера

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

Устройство отправляет следующие данные:

• Устройство ID (в URL)

• Идентификатор типа передачи из уведомления нажатия (в URL)

• Последний тег обновления, что это замечено по этому идентификатору типа передачи (как дополнительный запрос)

Маркеры авторизации указаны каждой передачей, таким образом, нет никакого надлежащего маркера в этом случае. Идентификатор устройства достаточен, чтобы доказать, что запрос допустим.

Ваш сервер определяет, какие передачи изменились начиная с того тега обновления. Это возвращает порядковые номера тех передач и новый тег обновления для хранения.

Для отправки списка порядковых номеров сделайте следующее:

1. Смотрите на регистрационную таблицу и определите, для каких передач устройство регистрируется.

2. Смотрите на таблицу передач и определите, какие передачи изменились начиная с данного тега. Не включайте порядковые номера передач, для которых не регистрировалось устройство. Если никакой тег обновления не предоставлен, возвратите все передачи, для которых регистрируется устройство. Например, это происходит в самый первый раз, когда устройство связывается с Вашим сервером.

3. Сравните теги обновления для каждой передачи, изменившей и определяющей, какой является последним. Это - тег обновления, который будет возвращен к устройству.

4. Ответьте этим списком порядковых номеров и последнего тега обновления в полезной нагрузке JSON — например:

   {

   "serialNumbers" : ["001", "020", "3019"],

   "lastUpdated" : "1351981923"

   }

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

Система тега подобна стандартному механизму HTTP, «Если Изменено С тех пор», но отличается важным способом. Стандартный механизм HTTP для единственного монолитного ресурса; если ресурс изменился, весь ресурс возвращается. Система тега, используемая здесь, для набора передач; только изменившиеся передачи возвращаются, не весь набор.

Устройства просят последнюю версию передач

Устройство просит у Вашего сервера последнюю версию каждой обновленной передачи. Чтобы доказать, что запрос допустим, устройство включает маркер авторизации передачи.

Устройство отправляет следующие данные:

• Передайте идентификатор типа (в URL)

• Порядковый номер (в URL)

• Аутентификационный маркер (в заголовке)

Если передача не изменилась, Ваш сервер возвращает данные передачи или состояние HTTP 304 Не Измененный. Поддерживайте механизм кэширования, «Если Изменено С тех пор» на этой конечной точке.

Сообщения изменения дисплея устройств

Устройство сравнивает последнюю версию передачи против версии, которую это имело прежде для определения, какие поля изменились. Если значение поля изменилось, и поле указывает сообщение изменения, устройство показывает сообщение для информирования пользователя об изменении.

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

Методы наиболее успешной практики

Поскольку Вы реализуете свой веб-сервис, помните следующие методы наиболее успешной практики:

• Всегда делайте резервное копирование своего закрытого ключа и сертификата и сохраняйте их в безопасном месте.

• Избегите хранить свои закрытые ключи на Вашем веб-сервере, потому что веб-серверы обычно имеют большую поверхность атаки. Более безопасный подход должен иметь различное создание дескриптора сервера и подписание передач, и продвинуть законченные передачи в Ваш веб-сервер.

• Порядковый номер, идентификатор типа передачи и последнее обновление тегируют, все включены в URL когда говорящий с Вашим веб-сервисом. Создание их чрезмерно долго могло вызывать проблемы с системами, налагающими ограничение на длину URL.

• Не изменяйте аутентификационный маркер в обновлении. Передачи, как гарантируют, не будут обновлены, таким образом, могли все еще быть устройства со старой передачей и старым аутентификационным маркером. Ваш сервер должен был бы проверить аутентификационный маркер по списку каждого маркера, который когда-либо был допустим.