MIME-RPC (was Re: REST)
Thu, 17 Jan 2002 09:48:55 -0800
"S. Alexander Jacobson" wrote:
> If the whole point of REST is to re-use what is
> already in use, why not use MIME types!
REST uses MIME types. The question is just where the appropriate
boundary between MIME and XML is. But REST doesn't need a new
specification to use MIME types. It just uses them.
> 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).
It is my assertion that most of the interesting web services will be
organized around these new mime-types (or at least XML namespaces). So I
don't see MIME-RPC as being a big part of the REST model.
The nice thing about
> MIME-RPC is that it defines coherent semantics for
> passing complex (and perhaps opaque) types between
> XML-RPC and SOAP both send base64encoded and
> provide no clear semantics for how to interpret
> the data sent.
SOAP with attachments uses MIME types.
> They are ugly but they realistically solve major
> problems with both SOAP and XML-RPC.
Okay, but REST doesn't really incorporate SOAP or XML-RPC, so they
aren't the appropriate comparison point.
> REST is wrong about using HTTP methods.
> 1. You may want to send messages over non HTTP
A few issues here:
* HTTP can be tunnelled over any transport.
* AFAIK, there do not yet exist non-HTTP transports that work properly
with the REST model.
* Arguably it is easier to adapt HTTP to new usage modes (through
extensions or tunnelling) than to adapt other protocols to REST.
> 2. A lot of web infrastructure alread assumes only
> GET/POST style requests and generic expansion of
> these limits interop.
This is true. That's why you must often work around with POST. But if
you're going to be REST-compatible then you should provide a mapping
between your workaround and real HTTP methods so that a MIME-RPC DELETE
is the same as an HTTP DELETE.
> 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).
This is basically the same problem as above.
> > 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.
My point is that XML Schema types are increasingly available in all
languages. MIME-RPC is going to impair interoperability if it defines
> 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
Okay, but you agree that the Web as we know it has no such problem. With
or without MIME-RPC, it is easy to pass highly structured data (objects)
over the Web. You define a MIME type (or at least an XML namespace) and
send your data. That's all you have to do!