Re: RFC: REST-RPC

Hi.

The only compelling argument for REST that I can recall at the moment is  
that RPC using post to a single URL bypasses any network security layers  
that may be in place.  If you want to restrict access to your web services  
(at a firewall for example) using URL pattern matching, you can't do so  
unless your web service is REST based.

Other arguments for REST tend to be more subjective and (to me) less  
compelling.  My initial confusion about REST and the primary argument  
against actually using REST as an equivalent to XML-RPC in the past is  
that it's more of a technique than a protocol.

In other words you have rest on one side and RPC using posted XML on the  
other.  XML-RPC is a specific example of a standard way of doing the  
second, SOAP is another example.  Both have a lot of interoperable  
implementations and that's a big part of the reason to use them.

It looks like REST-RPC is an attempt to fill that empty space on the REST  
side (and there may be other standards I haven't heard of).  If the uptake  
is good it shouldn't matter to most applications which thing you use.

The piece of the picture that's still lacking standardization (and I think  
this is weird) is the API applications use to make RPC calls.  Database  
APIs have had this for a long time.  If you have a perl or PHP script  
you're likely to be able to use a library for your database calls that  
would allow you to swap mysql for ODBC database without changing  
application code.  Even in same language implementations of the same RPC  
protocol there is little consistency to APIs so that even switching  
between PHP XML-RPC libraries requries updating all the RPC calls.


------------>N





On Wed, 15 Mar 2006 12:07:36 -0800, <[email protected]> wrote:

> I took a look at REST-RPC to see how it compares to XML-RPC.  There
> are some ideas I like in REST-RPC, but some of the apparently
> important differences I don't understand.
>
> Probably the most fundamental difference between the two is that
> REST-RPC doesn't use XML for the call.  It uses XML for the response,
> but the call is in a special language intended to go in the "parameter"
> piece of an HTTP GET header (I forget the actual name of that).  Here's
> an example of the HTTP traffic for a call:
>
>   GET /?_function=GetCart&cart=1563 HTTP/1.1
>   Host: test.rest-rpc.org
>   Accept: text/xml
>   Connection: close
>
> And for the response:
>
>   HTTP/1.1 200 OK
>   Content-Length: 114
>   Content-Type: text/xml
>   Connection: Close
>  <result>
>      <param name="creation">20050923T123507+0100</param>
>      <param name="priceAmount">60.5</param>
>      <param name="priceUnits">EUR</param>
>      <param name="itemCount">4</param>
>      <data>
>         <item product="8923" price="12" amount="3"/>
>         <item product="2108" price="24.5" amount="1"/>
>      </data>
>   </result>
>
>
> This is supposedly good because "[web] browsers can call such services
> directly."  What does that mean?  I can see that I could type a call
> into the "location" field of my browser and get the XML response on my
> screen, and I can't do that with XML-RPC.  But what good is that?  Is
> there some other way browsers can use REST-RPC?
>
>
> One other difference pointed out is that XML-RPC lacks "Unicode
> support."  What does that mean?  I know XML-RPC involves Unicode in
> that it specifies XML, and XML is defined in terms of Unicode code
> points.  What Unicode capability does REST-RPC have that is missing in
> XML-RPC?
>



-- 





---
(([^/]+)/([^/]+)){0,1}/*(([^/]+)/([^/]+)){0,1}/*(([^/]+)/([^/]+)){0,1}/*
(([^/]+)/([^/]+)){0,1}/*(([^/]+)/([^/]+)){0,1}/*(([^/]+)/([^/]+)){0,1}/*
---



Nathan Young
N. C. Young Design
(530)629-4176
http://ncyoung.com


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/