Search code examples
web-servicesapilanguage-agnosticxml-rpc

Is XML-RPC bad used as a protocol for a public API implementation?


I need to implement a web API for a project I'm working on in this period. I read there are many standard protocols to do it: XML-RPC, SOAP, REST. Apparently, the XML-RPC one is the easiest one to implement and use from what I saw, but I didn't find anything about using it to implement an API. Instead I found many tutorial about creating a REST API in PHP, for example. Is there any counter-indication for using XML-RPC to implement a public web API?

Also, more generally speaking, I could (sort of) define a custom protocol for my API, to keep things simpler (i.e. accepting only GET request containing the parameters I need): would this be so bad? Is using a standard protocol a must-do?


Solution

  • If your app is a very simple one, then there is nothing wrong with simply using GET requests and passing in parameters. You don't have to use some standard like SOAP.

    Technically you would use REST if what you are sending is entities. For example if you have domain objects which you want to transport, then these can be retrieved via a GET, updated via PUT all through a standard URL. Although many people refer to the first option above as rest, that is not entirely right.

    SOAP/XML-RPC are protocols that have libraries for every platform under the sun but are slowly dying due to their XML bloat and (relatively) complex schema. I am not a big fan of these protocols and they have never been that widely used. People may argue otherwise, but try and find a large web company that uses either for their public protocol and I'll buy that person a sandwich.

    Seems that JSON is taking over the world now. It's compact, fast to parse, and ideal for web apps as you can pipe it straight into javascript. You can get very far simply using a HTTP GET that returns JSON.