The Return of XmlCGI
One of my goals with my web services API is performance. I want quick turnaround times. Therefore, I decided to eschew the heavily-laden XML formats with something much more concise. However, writing the parser to handle all the data types I want to handle was simply too much effort.
There was one shining shortcut, though. I decided to try to upload the service request as a Ruby language compatible string which could be eval()’d into an argument hash, a la the following:
MyService.Function("argument" => "value")
Unfortunately, while quick, relying on eval() would leave an huge security hole open. Consider the following:
MyService.Function("argument" => File.unlink("../services/MyService.rb"))
What this would do is evaluate the File.unlink() function and delete the MyService service handler script, which would absolutely kill the service until I copied the code from my backup repository. Talk about a denial of service attack! So, eval() is out.
Instead, I’m going to modify my existing XmlCGI code into an argument parsing class and go back to uploading XmlCGI formatted service requests. This should be quick enough.
An XmlCGI request looks very similar to XML-RPC. However, while XML-RPC relies on the ordering of function arguments, like a procedural language, XmlCGI uses named arguments. This allows me to specify server-side function prototypes which would include mandatory and optional arguments. An XmlCGI request similar to the above would look like:
<?xml version="1.0"?>
<methodcall name="MyService.Function">
<param name="argument" type="string">
<value>value</value>
</param>
</methodcall>
Note that XmlCGI includes the data type of the uploaded arguments. I may remove this requirement and rely on server-side information to correctly parse the information.