MIME-RPC (was Re: REST)
S. Alexander Jacobson
Thu, 17 Jan 2002 19:27:23 -0800 (Pacific Standard Time)
On Thu, 17 Jan 2002, Paul Prescod 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.
MIME-RPC is not a new specification of MIME types
it is simply a formalization of common practice.
I am not sure what REST uses because there seems
to be no formal definition of what exactly REST
I think MIME-RPC would be almost identical to
such a formal definition if one were to create it.
> > 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.
I don't see what you are fighting. I think we
should be in raging agreement! If you want to
send a PO in MIME-RPC, just send it with header:
content type: application/x-purchase-order
If you want to send 10 purchase orders, use
If you want to send a tuple of a purchase order,
a signature, and a credit application, use
If you want a credit approval reply sent to a
different location, send a reply-to-url.
> 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.
> SOAP with attachments uses MIME types.
No the SOAP semantics are poorly defined. No
one seems to know whether applications should
interpret the attachment accoding to a type
provided in an XML schema or according the
content-type header associated with the
More generally, SOAP and XML plumbing seem like
ridiculous overhead when you simply want to send
an opaque PO!
> > 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.
You seem to be attacking SOAP and XML-RPC so the
appear relevant. I think MIME-RPC fixes their
problems in a way that should make RESTers happy.
> > REST is wrong about using HTTP methods.
> > 1. You may want to send messages over non HTTP
> > transports
> A few issues here:
> * HTTP can be tunnelled over any transport.
Unless you define a protocol for both ends of the
tunnel, you have no reliable way to deliver HTTP
over that transport. MIME-RPC specifies that
protocol. If REST ever gets specific, it might
look like MIME-RPC.
(Btw, RFC 1149 describes how to deliver IP
datagrams using carrier pigeon)
> * AFAIK, there do not yet exist non-HTTP transports that work properly
> with the REST model.
I assume this is because there is no way to do so
> * Arguably it is easier to adapt HTTP to new usage modes (through
> extensions or tunnelling) than to adapt other protocols to REST.
I don't think I follow. Why not just use other
protocols as is. The main argument for REST seems
to be the existence proof of widespread interop.
Email has the same property. MIME-RPC uses email
pretty much as is. It also supports using
e.g. IMAP as a transport or HTTPS!
> > 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.
Why? You seem to take REST as normative, but I
don't see why that is so. I think a transport
independent way of specifying methods allows
> > > 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
> types otherwise.
These types are there to be consistent with what
web browsers already send to web servers (without
More MIME-RPC aware applications are free to send
their own XML Schema derived content-types.
That being said, implementing support for these
types is trivial in most languages so I am not
sure that it matters so much.
> > 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.
> 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!
I do agree. MIME-RPC is largely a formalization
of existing practice, addressing the needs of
XML-RPC and SOAP people for an easy to reference
spec with which they can declare compliance!
I think we are in agreement.
S. Alexander Jacobson i2x Media
1-212-787-1914 voice 1-603-288-1280 fax