MIME-RPC (was Re: REST)

S. Alexander Jacobson alex@shop.com
Thu, 17 Jan 2002 09:01:08 -0800 (Pacific Standard Time)


On Wed, 16 Jan 2002, Paul Prescod wrote:
> "S. Alexander Jacobson" wrote:
> >
> > This sounds interesting, but there is no spec.
>
> Although I don't agree with the tone (<grin>) I agree with the thrust of
> Jeff Bone's message, that most of the specs are in place.
>
> Nevertheless, there is a need for conventions of what exactly to send
> over the wire to represent structured data. I think that the REST
> community needs to clarify this.

If the whole point of REST is to re-use what is
already in use, why not use MIME types!
That is what is already used to make the web and
email work!

> I would have to think through MIME-RPC to determine its strengths and
> weaknesses w.r.t. SOAP, "raw XML" etc. I'm trying to imagine using
> MIME-RPC to represent a highly structured document like a purchase
> order. Would you have a multi-part containing a multi-part containing a
> multi-part and so forth? If so, you are re-inventing XML in an even more
> (!) verbose syntax.

No.  That is not my intention.  For highly
structured documents, like a purchase order, I
assume you define some new mime-type (that may
itself be an XML document).  The nice thing about
MIME-RPC is that it defines coherent semantics for
passing complex (and perhaps opaque) types between
applications.

XML-RPC and SOAP both send base64encoded and
provide no clear semantics for how to interpret
the data sent.

> MIME-RPC's Rule 4. is not a good idea in my opinion.

I have mixed feelings about it as well.  In
practice, I think it corresponds better to what
happens when people send urlencoded data.

And I prefer these defaulting rules to defaulting
to text/plain which is the only alternative.

I was also thinking about eliminating urlencoded
data entirely, but the installed base is too
large.

> MIME-RPC's Rule 6 and 7 are ugly and anyways, part of the REST
> philosophy is that you shouldn't do function calls. You should use HTTP
> methods.

They are ugly but they realistically solve major
problems with both SOAP and XML-RPC.

REST is wrong about using HTTP methods.
1. You may want to send messages over non HTTP
	transports

2. A lot of web infrastructure alread assumes only
GET/POST style requests and generic expansion of
these limits interop.

3. Many people will want to use this protocol who
do not have sufficient control over the httpd to
add new HTTP methods (e.g. ISP security policy
only allows GET/POST and they are restricted in
various ways when hitting ~user style accounts).

> MIME-RPC's numeric types should probably be XML Schema numeric types
> rather than inventing Yet Another Type System.

Nothing is stopping you from defining your own
mime-types.  The ones in the spec are there for
ease of use, readability, and compatibility with
deployed applications.

> What if two partners want to send highly structured data back and forth
> using MIME-RPC. What formalism (i.e. schema) can they use to declare the
> allowed values for the structure type? XML-haters (you may or may not
> fall into this category) tend to forget that the schema (or DTD) is one
> of the core concepts of XML and you can't have a replacement for XML
> (e.g. S-expressions) without having a replacement for schemas/DTDs.

A major point of MIME-RPC is that they can send
whatever they want in whatever format they want.
They just have to document it as a MIME
content-type.  One of the reasons for MIME-RPC was
the incredible difficulty XML-RPC and SOAP have in
sending highly structured data (objects) as
arguments.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax