On Wed, 2012-01-11 at 22:35 +0200, Dan Kenigsberg wrote:
On Wed, Jan 11, 2012 at 12:10:04PM -0800, David Lutterkort wrote:
> > >
> > > In practical terms, the blob of data should be passed to the
> > > 'start VM' call base64 encoded, and RHEV-M should decode
it
> > > just
> > > before putting it into its proper place.
> >
> > This requirement is not clear, why not just pass data as 'binary' to
> > 'start vm' and vdsm would write as is into the file, REST already
> > knows how to encode/decode.
>
> I mostly mentioned base64 because that's how other API's (EC2, RAX)
> encode6 this data; to be pedantic, it's not REST that determines the
> encoding, but how the request payload is serialized (XML, JSON,
> application/x-www-form-urlencoded ..) The nice thing about base64 is
> that it works with all of them, without requiring add'l encoding, but
> ultimately anything works that allows passing arbitrary binary blobs as
> user_data.
But base64 is the additional encoding... I'm generally reluctant to intorduce
an application-level encoding if the transport already has one. Does any REST
serializer have a problem with natively chewing binary data (I really do not
know)?
There's no such thing as a REST serializer; serialization is handled by
whatever you use to process your payloads (XML, JSON, ...) and the
libraries people use for that have to handle serialization-specific
encodings; base64 is a little friendlier for really underpowered
clients, like shell scripts.
Don't underestimate how much people automate armed with little more than
bash and curl - making that easy is one of the big attractions of REST.
David