Как разработать высокоуровневый прикладной протокол и формат данных для синхронизации метаданных между устройствами и сервером?

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

Моя цель: пользователь может взаимодействовать с данными приложения по любому устройству, или в сети. Цель этого протокола состоит в том, чтобы передать изменения, внесенные на одной конечной точке в другие конечные точки через сервер, и гарантировать, чтобы все устройства поддержали последовательное изображение данных приложения. Если пользователь внесет изменения на одном устройстве или в сети, то протокол продвинет данные к центральному репозиторию, от того, где другие устройства могут вытянуть его.

Некоторые другие мысли дизайна:

• Я называю его "синхронизацией метаданных", потому что полезные нагрузки будут довольно маленькими, в форме идентификаторов объектов и маленьких метаданных о тех идентификаторах. Когда клиентские конечные точки получат новые метаданные по этому протоколу, они выберут данные фактического объекта из внешнего источника на основе этих метаданных. Выборка "реальных" данных объектов вне объема, я только говорю о метаданных, синхронизирующих здесь.
• Используя HTTP для транспорта и JSON для контейнера полезной нагрузки. Вопрос в основном о том, как лучше всего разработать схему полезной нагрузки JSON.
• Я хочу, чтобы это было легко реализовать и поддержать в сети и через настольные и мобильные устройства. Лучший подход чувствует, чтобы быть простым таймером - или основанный на событии Запрос HTTP / ответ без любых персистентных каналов. Кроме того, у Вас не должно быть доктора философии для чтения его, и я хочу, чтобы моя спецификация соответствовала на 2 страницах, не 200.
• Аутентификация и безопасность вне объема для этого вопроса: предположите, что запросы безопасны и аутентифицируются.
• Целью является возможная непротиворечивость данных по устройствам, это не совсем в реальном времени. Например, пользователь может внести изменения на одном устройстве будучи в режиме офлайн. При движении онлайн снова, пользователь выполнил бы "синхронизирующую" операцию, чтобы продвинуть локальные изменения и получить удаленные изменения.
• Однако протокол должен поддерживать оба из этих режимов работы:
  • При запуске с нуля на устройстве, должен смочь вытянуть целое изображение метаданных
  • "синхронизируйте, когда Вы идете". При рассмотрении данных по двум устройствам рядом и внесении изменений, должно быть легко продвинуть те изменения, поскольку короткий человек обменивается сообщениями, который другое устройство может получить псевдореальное время (подвергающийся тому, когда это решает связаться с сервером для синхронизации).

Как конкретный пример, можно думать о Dropbox (это не то, что я продолжаю работать, но он помогает понять модель): на диапазоне устройств пользователь может справиться, файлы и папки — перемещают их, создают новые, удаляют старые и т.д. И в моем контексте "метаданные" были бы файловой структурой и структурой папок, но не фактическим содержанием файла. И поля метаданных были бы чем-то как файл/имя папки, и время модификации (все устройства должны видеть то же время модификации).

Другим примером является IMAP. Я не прочитал протокол, но моими целями (минус фактические тела сообщения) является то же.

Чувствует, что существует два главных подхода, как это сделано:

• транзакционные сообщения. Каждое изменение в системе выражается как дельта, и конечные точки общаются с теми дельтами. Пример: DVCS changesets.
• REST: передача графа объектов в целом или частично, не вызывая беспокойство так об отдельных атомарных изменениях.

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

• Существует два класса: подача и объекты.
• Я могу добавить, переименовать и удалить подачу. Добавление канала подписывается на него и начинает получать объекты для того канала. Я могу также переупорядочить порядок дисплея канала в UI.
• Когда я считал объекты, они отмечены как чтение. Я не могу отметить их непрочитанный или сделать что-либо еще с ними.
• На основе вышеупомянутого объектная модель:
  • "канал" имеет атрибуты "URL", "displayName" и "displayOrder" (displayOrder индекс канала в списке UI подачи; переупорядочение подачи локально изменяет displayOrder всей подачи так, чтобы индексы остались уникальными и последовательными).
  • "объект" имеет атрибуты "URL", и "непрочитанное", и many-one отношение "питаются" (каждый объект принадлежит одного канала). "URL" также ведет себя как GUID для объекта.
  • фактическое содержание объекта загружается локально на каждом устройстве и не является частью синхронизации.

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

(закончите редактирование),

Что я хотел бы в ответах:

• Действительно ли там что-нибудь важно, я не учел выше? Ограничения, цели?
• Каково некоторое хорошее дополнительное чтение по этому? (Я понимаю, что это - то, о чем говорят много курсов информатики в большой длине и детали... Я надеюсь закоротить его путем рассмотрения некоторого интенсивного курса или самородков.)
• Каковы некоторые хорошие примеры таких протоколов, которые я мог смоделировать после, или даже использовать из поля? (Я упоминаю выше Dropbox и IMAP... Я должен, вероятно, считать RFC IMAP.)