Может ли AMF использоваться как «просто другой формат вывода» из веб-службы?

Question

Я работаю над проектом сервера RESTish, который отвечает на запросы HTTP в различных форматах. Это позволяет нам писать приложения, обращенные к пользователю, и извлекать любой формат, который в то время был наиболее удобным. Например, чтобы узнать, есть ли пользователь вошел в систему, мы можем отправить:

http://serverurl/Authentication?command=whoami&format=xml 

Как вы можете себе представить, это возвращает XML, содержащий информацию о вошедшего пользователя (если таковые имеются). Мы можем получить ту же информацию обратно в JSON:

http://serverurl/Authentication?command=whoami&format=json 

Недавно мы обсуждали добавить поддержку для YAML, так как он популярен с некоторыми рубин и питона разработчиков. В то же время мы говорим о написании прототипа клиентского приложения в Flex (которое, если вы не можете сказать из моего вопроса, будет нашим первым набегом на разработку Flex). Я понимаю, что мы можем использовать один из наших существующих форматов для связи с Flex-приложением, но если мы решили добавить поддержку этих дополнительных форматов «только потому, что можем», есть ли что-то, что сделало бы использование amf особенно сложным или отличным от вывод xml или json?

Answer 1

AMF - это RPC (Remote Procedure Call) формат, похожий на SOAP, но с другой целевой аудиторией. Поскольку существует фундаментальное различие между вызовом процедуры и объектом, AMF равен , а не, который будет просто другим форматом вывода для вас.

Возможно, вам следует подумать о том, что AMF «Flex Remoting», а не как выходной формат, ориентированный на Flex, используя ваш REST API.

Чтобы сделать аналогию: подумали бы вы о SOAP или XMLRPC как о другом формате вывода для REST API?

Answer 2

AMF - это формат сообщений о действии, и это просто способ кодирования данных в очень компактном двоичном формате. AMF не привязан к RPC в каком-либо строгом смысле. Функции обмена сообщениями, доступные в Flex (Consumer/Producer), используют AMF для кодирования данных для всех сообщений, и это определенно не RPC.

. Вернуться к вопросу: какие серверные технологии вы используете для создания своего приложения? Библиотеки AMF для различных платформ различаются по качеству и зрелости. Большинство этих библиотек должны позволить вам просто передать объект, который вы хотите закодировать и получить массив байтов, который вы можете записать в выходной поток HTTP-запроса, привязанного к вашей конечной точке REST.

Answer 3

В ответ на вопрос Vineet Bhatia: Вы проверили BlazeDS? http://opensource.adobe.com/wiki/display/blazeds/Overview

Answer 4

Ya вы можете это сделать, но вам придется написать собственный сериализатор AMF и десериализатор (просто скопируйте его в Zend Framework). Или ты можешь дождаться, когда я закончу добычу. Я постараюсь запомнить его здесь.

Answer 5

В настоящее время я работаю на платформе с использованием AMF в формате сериализации точно так же, как вы предлагаете (на платформе .NET). Что мы делаем:

1. Создайте DTO, который представляет страницу, которую вы хотите отправить.
2. Создать ByteArray и сохранить DTO в нем с помощью WriteObject()
3. Изменение типа содержимого в AMF
4. Binary записать буфер ByteArray в поток ответа

На стороне клиента, мы используем обычный URLLoader с установленным в двоичный формат. Свойством loader.data будет ByteArray и с использованием ReadObject, вы получите сериализованный DTO. Если вы используете метаданные [RemoteClass] и registerClassAlias, вы получите соответствующий тип - в противном случае вы получите общий объект с некоторыми динамическими свойствами.

Прохладная вещь, взяв обход вокруг типизированного DTO, состоит в том, что мы можем использовать на нем обычные XML или JSON-сериализаторы, что делает формат версий очень простым.

Я также проверил тесты с отправкой ByteArrays на сервер для создания/обновления и, похоже, работает нормально. Итак, вы можете теперь использовать AMF для REST.

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