Re: Error reporting other than a fault

On Wed, May 21, 2008 at 04:51:10PM +0000, [email protected] wrote:
> >So, I'm returning an error but it's not an XML-RPC fault.
> 
> Yes.  It's not only better than extending XML-RPC, it's the right
> architecture anyway.  Errors should be layered.

Bryan,

Both you and John responded about avoiding extending the XML-RPC spec.
I hope I was clear, I'm not suggesting that.  For example, I was not
suggesting that the XML-RPC fault response be extended.

My situation is a request may fail, and I may have more than one
failure to report (maybe multiple parameters are formatted
incorrectly).

And the XML-RPC spec for a fault, IIUC, only allows a integer and a
single string.  So my options are to a) somehow serialize all my
messages into the fault string or b) come up with a higher-level error
system in the payload as I described in my initial email.

I believe your responses were that adding a higher-level error system
into the payload is the way to go.

Indeed, if I was writing the client and server side of the code then
XML-RPC would only be an "encoding" format for transport that was
hidden by the user of the client software.[1]

> In fact, ideally the "call" function in the client XML-RPC library
> returns its own failures with text messages, and the caller doesn't
> even have to distinguish between a failure at the server and a network
> problem that prevents sending the RPC at all.  In both cases, the
> program sees a generic failure and displays an explanatory error
> message.

In my case I'm only exposing the service.  So, I have no control over
what client library someone uses.  A PHP programmer may use Incutio,
and a Perl programmer may use RPC::XML::Client.  It's up to the
programmer to make sure their library deals with HTTP errors
correctly and handles XML-RPC faults.  But, after that it's up to me
to document that the payload contains a status element and potentially
a struct that details errors associated with a given input parameter.

It's up to the client programmer to determine if they want to provide
a more abstract layer or not.

Seems reasonable to me. ;)

But, I do want to make sure that it's not too difficult for people to
use.  That's really why I posted in the first place -- to ask if my
approach of have a separate status and error in the payload seemed
reasonable.


BTW -- I was looking at the Flickr API.  Their response shows
they use the RPC-XML fault for errors:

    http://www.flickr.com/services/api/response.xmlrpc.html

They use a defined set of error codes, for example on this method:

    http://www.flickr.com/services/api/flickr.blogs.getList.html


Which seems to limit Flickr to a single error condition.  I'm not too
interested in trying to create, maintain, and document a bunch of
error codes that might get out of sync with the application.

Thanks very much for you comments,



[1] Truth be told, both XML-RPC and HTTP's multipart/form-data and
application/x-www-form-urlencoded are all treated as just encodings.
The application, in general, has no idea of how the input data was
encoded or how it will be encoded in the response, be it HTML,
RPC-XML, JSON, or whatever.

-- 
Bill Moseley
[email protected]


------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/xml-rpc/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> 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/