Custom Protocols
XML-RPC is vastly underpowered for many tasks (for example, any that require strings in a language other than English), whereas SOAP is perhaps overcomplicated for many jobs. There is, however, a convenient middle ground. The truly key idea for both SOAP and XML-RPC is that you can pass an XML document over the Web using HTTP POST. The exact format of that data doesn't really matter much, as long as both client and server agree on what it is and what it means.
For example, if an online broker such as Ameritrade wanted to provide its clients specialized trading software, it could use any XML format it wanted to send the data back and forth. It might choose to ignore the SOAP envelope completely and just send the getQuote and Buy elements I've been placing in the body of the SOAP requests.
There are still many advantages to using a standard format for exchanging data rather than rolling your own every time you need one. Most important, a standard format such as XML-RPC or SOAP makes it much easier for other developers to integrate their systems with yours. Furthermore, if your system can be easily modeled as a set of procedure calls, then choosing XML-RPC or SOAP allows you to pick from a variety of implementations that take care of many of the details for you. Therefore, you shouldn't go the custom protocol route without some serious thought as to whether it's truly appropriate. Nonetheless, if a custom XML vocabulary does seem to suit your problem, feel free to define one.
|
