Я ищу руководство о том, как лучше всего подумать о разработке протокола приложений высокого уровня для синхронизации метаданных между устройствами конечного пользователя и сервером.
Моя цель: пользователь может взаимодействовать с данными приложения на любом устройстве или в Интернете. Целью этого протокола является передача изменений, внесенных в одной конечной точке, в другие конечные точки через сервер и обеспечение того, что все устройства поддерживают согласованную картину данных приложения. Если пользователь вносит изменения на одном устройстве или в Интернете, протокол передает данные в центральное хранилище, откуда другие устройства могут их извлекать.
Некоторые другие мысли о дизайне:
- Я называю это «синхронизацией метаданных», потому что полезные данные будут довольно маленькими, в форме идентификаторов объектов и небольших метаданных об этих идентификаторах. Когда клиентские конечные точки получают новые метаданные по этому протоколу, они извлекают фактические данные объекта из внешнего источника на основе этих метаданных. Извлечение «реальных» данных объекта выходит за рамки, я говорю только о синхронизации метаданных здесь.
- Использование HTTP для транспорта и JSON для контейнера полезной нагрузки. Вопрос в основном в том, как лучше спроектировать схему полезной нагрузки JSON.
- Я хочу, чтобы это было легко внедрить и поддерживать в Интернете, на настольных и мобильных устройствах. Наилучший подход - простой HTTP-запрос / ответ на основе таймера или события без постоянных каналов. Кроме того, у вас не должно быть докторской степени, чтобы прочитать его, и я хочу, чтобы моя спецификация помещалась на 2 страницах, а не на 200.
- Аутентификация и безопасность выходят за рамки этого вопроса: предположим, что запросы безопасны и аутентифицированы.
- Целью является возможная согласованность данных на устройствах, они не полностью в реальном времени. Например, пользователь может вносить изменения на одном устройстве, находясь в автономном режиме. При повторном подключении к сети пользователь будет выполнять операцию «синхронизации» для передачи локальных изменений и извлечения удаленных изменений.
- Сказав это, протокол должен поддерживать оба из этих режимов работы:
- Начиная с нуля на устройстве, должен иметь возможность извлекать всю картинку метаданных
- "синхронизировать, как вы идете". При одновременном рассмотрении данных на двух устройствах и внесении изменений должно быть легко представить эти изменения в виде коротких отдельных сообщений, которые другое устройство может получить почти в реальном времени (при условии, что оно решит связаться с сервером для синхронизации).
В качестве конкретного примера вы можете вспомнить Dropbox (это не то, над чем я работаю, но помогает понять модель): на ряде устройств пользователь может управлять файлами и папками - перемещать их вокруг, создавать новые, удалять старые и т. д. И в моем контексте «метаданными» будет структура файла и папки, но не фактическое содержимое файла. А поля метаданных будут выглядеть примерно так: имя файла / папки и время изменения (все устройства должны видеть одинаковое время изменения).
Другой пример - IMAP. Я не читал протокол, но мои цели (за исключением реальных тел сообщений) совпадают.
Чувствуется, что есть два грандиозных подхода к этому:
- транзакционные сообщения. Каждое изменение в системе выражается как дельта, и конечные точки связываются с этими дельтами. Пример: наборы изменений DVCS.
- REST: передача графа объектов целиком или частично без особого беспокойства об отдельных атомных изменениях.
РЕДАКТИРОВАТЬ: некоторые ответы справедливо говорят, что недостаточно информации о приложении, чтобы предложить достаточно хорошие предложения. Точная природа приложения может отвлекать, но очень простое приложение для чтения RSS является достаточно хорошим приближением. Допустим, спецификация приложения следующая:
- Существует два класса: фиды и предметы.
- Я могу добавлять, переименовывать и удалять каналы. Добавление канала подписывается на него и начинает получать элементы для этого канала. Я также могу изменить порядок отображения каналов в пользовательском интерфейсе.
- Когда я читаю статьи, они помечаются как прочитанные. Я не могу пометить их как непрочитанные или сделать что-либо еще с ними.
- Исходя из вышеизложенного, объектная модель:
- «канал» имеет атрибуты «url», «displayName» и «displayOrder» (displayOrder - это индекс канала в списке каналов пользовательского интерфейса; изменение порядка каналов локально изменяет displayOrder всех каналов, чтобы индексы оставались уникальными и последовательными).
- «item» имеет атрибуты «url» и «unread», а также отношение «один к одному» «feed» (каждый элемент принадлежит одному фиду). «url» также ведет себя как GUID для элемента.
- фактическое содержимое элемента загружается локально на каждое устройство и не является частью синхронизации.
На основе этого дизайна я могу настроить свое приложение на одном устройстве: добавить несколько каналов, переименовать и изменить их порядок, а также прочитать на них некоторые элементы, которые затем будут помечены как непрочитанные. Когда я переключаю устройства, другое устройство может синхронизировать конфигурацию и показывать мне тот же список каналов с такими же именами, порядком и тем же состоянием чтения / непрочитанных элементов.
(конец редактирования)
Что бы я хотел в ответах:
- Есть что-то важное, что я оставил выше? Ограничения, цели?
- Что хорошего по этому поводу? (Я понимаю, что это то, о чем многие курсы информатики рассказывают очень подробно и подробно ... Я надеюсь коротко замкнуть его, посмотрев на какой-нибудь ускоренный курс или самородки.)
- Какие есть хорошие примеры таких протоколов, которые я мог бы смоделировать после или даже использовать из коробки? (Я упоминаю Dropbox и IMAP выше ... Я, вероятно, должен прочитать IMAP RFC.)