What is it?
CGI-RPC is a proposed standard for calling a remote procedure. It uses the CGI spec for all calls. Consequently the spec is almost completely concerned with the format of the returned data, not with the calling convention. This addresses the one limitation of CGI that it does not structure the returned data in a form that is guranteed to be machine readable.

The intention is that the standard should be inherently resilient and make few, if any, assumptions about the language or the environment of the client and server.

Why?
CGI-RPC grows out of a frustration with XML-RPC and SOAP implementations. And also with the work being done on the REST philosophy of application design.

RPC is about one application making a function call to another application and getting some data back in a machine readable format. The CGI functions provide all the function that appear to be necessary to make the call. This can be done in a RESTful way or not, but it's inherently more RESTful than XML-RPC or SOAP. But there appears to be no CGI standard for returning data. It assumes that it will be returning html which is inherently unstructured and impossible to parse in any general way. CGI-RPC is trying for the simplest possible XML format for the returning data in the same spirit as the simplicity and power of CGI.

Previous RPC conventions and standards such as XML-RPC and SOAP suffer from a number of inter-related problems.

1) XML-RPC is inherently brittle. It's use of un-named and ordered parameters mean that any change in requirements breaks all existing implementations.

2) All previous RPC standards use strong typing to an intermediate type set. This is inevitably a bad match to the type standards of the languages used for implementation.

3) They have grown and grown until there are serious problems with interoperability.

4) The toolkits are immature and fragile.

By contrast there are a large number of well tested implementations of CGI. And simple XML parsers are now robust. The CGI-RPC proposal is so simple that a parser can be written using simple string manipulation.

Philosophy
CGI-RPC is an attempt to produce an RPC convention that is as simple as possible. It has *just* enough in it to do useful work, and no more. Any suggested extensions to the standard should have occam's razor applied. If they are not essential they should be removed. The intention is that even if the standard changes, calls and results should be both forwards and backwarsd compatible.

This cannot be stressed enough. CGI-RPC should be necessary and sufficient and no more.

Calling a remote procedure
Procedures are called using CGI, GET, POST, HTTP as defined by the W3C.

Returned Data
The returned file should be valid XML. All text and data within elements should have reserved characters escaped.

Returned data is not typed. It is the responsibility of the reading program to type data as needed.

The <cgirpc> element should contain one or more <result> elements or the <fault> element but not both. Either the call is successful or it is not.

Implementations are strongly encouraged to name <result> elements eg <result name="foo">. If this is not done, then readers should assume that repeated <result> elements are part of a Scalar array.

Specific elements

<?xml version="1.0"?>
Required: Yes (by XML spec)

<cgirpc version="0.1"></cgirpc>
Parent: top level
Contains: <result>* or <fault>
Required: Yes

<result[name=""]></result>
Parent: <cgirpc>, <result>
Contains: a string value or one or more <result>
Used for: Returns data
Required: A <cgirpc> should contain at least one <result> or the two required <fault>
Notes:
- May be nested.
- optional (but recommended) parameter "name"

<fault id=""></fault>
Parent: <cgirpc>
Used for: Error information
Required: If there is no <result> then a <fault> is required. More <fault> may be added.
<fault id="[Integer error code]">[descriptive string]</fault>
Notes:
- May be nested.
- optional (but recommended) parameter "id"
- Additonal <fault elements may be added as requried.

Examples


1) A simple result

<?xml version="1.0"?>
<cgirpc version="0.1">
<result name="state">South Dakota</result>
</cgirpc>

2) A Structure

<?xml version="1.0"?>
<cgirpc version="0.1">
<result name="foostruct">
<result name="foo1">bar1</result>
<result name="foo2">bar2</result>
</result>
<result name="myarray">
<result>foo1</result>
<result>foo2</result>
</result>
<result name="state">South Dakota</result>
</cgirpc>

3) An Error

<?xml version="1.0"?>
<cgirpc version="0.1">
<fault id="3">Parameter stateid not found</fault>
</cgirpc>


[ << Simplicity and resilience in standards ] [ Business Plans for Software Development >> ]
[ 0 comments ] [ G ] [ # ]