jsonrpc2 возвращает удаленную ссылку - PullRequest
Новая
       24

jsonrpc2 возвращает удаленную ссылку

1 голос
/ 18 ноября 2011

Я изучаю jsonrpc 2 для веб-службы. У меня есть некоторый опыт работы с Java RMI, и мне очень понравилось это. Для простоты я использую Zend Framework, поэтому я думаю, что мне нравится использовать эту библиотеку. Однако есть одна вещь, по которой я скучаю. Как сделать процедуру отправить ссылку на другой объект.

Я понимаю, что это не входит в протокол, потому что речь идет о процедурах, но это все равно будет полезно. Как и в случае с java rmi, я мог выбирать объекты для отправки по значению (сериализация) или по ссылке (прокси удаленного объекта). Так каков наилучший способ решить эту проблему? Существуют ли какие-либо стандарты для этого, что большинство библиотек используют?

Я провожу часы просмотра в Google в поисках этого и могу придумать решение (например, вернуть URL), но я бы предпочел использовать стандарт, а не создавать что-то новое.

Есть еще одна вещь, о которой я хотел бы узнать ваше мнение. Я слышал, как рэнд-архитектор рассказал об особенностях протокола отправки пакетов вызовов. Считаются ли они хорошими или грязными? (он думает, что они безобразны, но я могу подумать о пользе для этого)

обновление

Я думаю, что хороший способ - просто вернуть объект remoteref с URL-адресом объекта. Таким образом, это всего лишь небольшая упаковка и небольшая документация. Тем не менее, я хотел бы знать, есть ли коммен-способ сделать это.

SMD Posibilitie's

Может быть какой-то способ указать тип возвращаемого значения в моем smd, есть кто-нибудь с идеями о том, как дать ссылку на другую страницу в моем возвращаемом типе smd? Или кто-нибудь знает хорошее объяснение для класса zend_json_smd?

1 Ответ

0 голосов
/ 14 ноября 2012

Вы не можете вернуть ссылку любого вида через JSON-RPC.

Не существует стандарта для этого (afaik), поскольку RPC не имеет состояния, и большинство разработчиков предпочитают его таким образом.Именно эта простота делает JSON-RPC столь желательным для разработчиков на стороне клиента через SOAP (и другие беспорядки).

Однако вы можете принять соглашение в возвращаемых значениях, согласно которому некоторые конструкции JSON следует рассматривать как «сигналы»изготовить удаленные «объектные» прокси.Например, вы можете создать модифицированный десериализатор JSON, который превращает: 

{
    "__remote_object": {
        "class":     "Some.Remote.Class",
        "remote_id": 54625143,
        "smd":       "http://domain/path/to/further.smd",
        "init_with": { ... Initial state of object ...  }
    }
}

в прокси удаленного объекта:

  • , создавая локальный объект с прототипом с именем class, инициализируется через init_with
  • , загружая и обрабатывая smd URL
  • , создавая локальный метод прокси (в прокси-объекте объекта) для каждой процедуры, предоставляемой через API, так что онипередавайте remote_id серверу при каждом вызове (чтобы сервер знал, какой прокси удаленного объекта сопоставлен с каким объектом на стороне сервера).

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

Сам JSON-RPC не очень хорошо стандартизирован, поэтому большинство расширений (даже SMD) являются просто соглашениями вокругимена методов и полезные нагрузки.

...