MIME-RPC (was Re: REST)

[Paul Prescod]

"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
> 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. 

>...
> 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
>         transports

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
types otherwise.

>....
> 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!

 Paul Prescod