views:

420

answers:

6

I'm working on a RESTish server project that responds to HTTP requests in a variety of formats. This allows us to write user facing applications and retrieve whichever format seems most convenient at the time. For example, to see if there is a user logged in, we can send:

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

As you can imagine, this returns XML that contains information about the logged in user (if any). We can get the same information back in json:

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

Recently, we've been discussing adding support for yaml, since it's popular with some ruby and python developers. At the same time, we have been talking about writing a prototype client application in Flex (which, if you can't tell from my question, would be our first foray into Flex development). I do understand that we can use one of our existing formats to communicate with a Flex app, but if we decide to add support for these additional formats "just because we can", is there something that would make using amf especially difficult or different from outputting xml or json?

A: 

AMF is an RPC (Remote Procedure Call) format, much like SOAP, but with a different target audience. Since there's a fundamental difference between a procedure call and an object, AMF is not going to be just another output format for you.

You should probably think of AMF as "Flex Remoting" and not as an output format targeted at Flex using your REST API.

To make an analogy: would you think of SOAP or XMLRPC as just another output format for a REST API?

bzlm
+1  A: 

AMF is the Action Message Format and it's simply a way of encoding data in a very compact binary format. AMF is not tied to RPC in any strict sense. The messaging features available in Flex (Consumer / Producer) use AMF to encode the data for all messages and this definitely not RPC..

Back to your question: what server-side technology are you using to build your application? The AMF libraries for various platforms are all of varying quality and maturity. Most of these libraries should allow you to simply pass the object you want to encode and receive byte array that you can write to the output stream of the HTTP request tied to your REST endpoint.

cliff.meyers
A: 

I have a similar question. Does anyone know of any server-side java libraries which will convert between AMF, JSON, XML?

Vineet Bhatia
A: 

In response to Vineet Bhatia's question: Have you checked out BlazeDS? http://opensource.adobe.com/wiki/display/blazeds/Overview

Rob Lund
A: 

Ya you can do it but you'll have to write your own AMF serializer and deserializer (just copy the one in Zend Framework). Or you can wait for me to finish mine. I'll try to remember to post it here.

+1  A: 

I am currently working on a platform using AMF as a serialization format in exactly the way you're proposing (on .Net platform). What we do is:

  1. Create a DTO that represents the page you want to send.
  2. Create a ByteArray and store the DTO in it using WriteObject()
  3. Change the Content Type to AMF
  4. Binary write the Buffer of the ByteArray to the Response stream

On the client side, we use a regular URLLoader with format set to binary. The loader.data property will be a ByteArray and using ReadObject, you get the serialized DTO. If you use [RemoteClass] metadata and registerClassAlias, you will get the corresponding type - otherwise you get a generic object with some dynamic properties.

The cool thing with taking the detour around a typed DTO is that we can use regular XML or JSON serializers on it, making the format versioning extremely simple.

I have also run tests with posting ByteArrays back to the server for Create/Update and it seems to work fine. So In essence, you can now use AMF for REST.

I am also looking into using this for server to server communication since it is light weight and seems to very robust for serializing complex types.

Johan Öbrink