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 i开发者_Python百科mplement 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?

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.

Why not just use SOAP, which is a lot easier to implement on many platforms.

Maybe if you're using a platform with no support for SOAP, then it might be easier to use XML-RPC. But then, most platforms do not have XML-RPC support.

The SOAP protocol was based on XML-RPC, which pretty much made XML-RPC much less useful.

To answer your question, I think SOAP or RESTful API would be the best to implement as consumers of your API would likely have more experience with them.

Additionally, your last bit, where you talk about accepting get requests with specific parameters, that is a very large part of designing a RESTful API. If you think that would be easy to implement, I strongly encourage you to do some research on building a RESTful API in your language of choice, because I think you will find it very close to the alternate solution that you proposed.

Our application provides all three protocols

• Plain HTTP
• XML RPC
• SOAP

From our experience a beginner or resource oriented user is using plain HTTP. Some (not many) opted to use XML RPC. Mostly when they are new to the topic and do not have many service API's around. High end users and technology loving ones go for SOAP.

Me i think days of XML-RPC are over. Either go for plain HTTP POST (which i prefer if you're able to define a clean service signature, good candidates are ones that only have primitive types, no real sense of objects) or choose SOAP if you are not resource restricted.

I'd prefer even "newer" ones like JSON RPC over XML RPC. JSON may be a good choice if you need more then plain primitive parameter signatures.

The downsides would be that you will be defining your own semantics for operating on resources (which your client developers will need to learn) when you could use the operations that already exist.

HTTP defines the operations/actions/verbs that can be used. If you use this, you can provide a uniform interface that api users can call without being forced to learn your new plans.

Doing so would allow you to achieve one of the helpful constraints in REST.

Well. I had to make a magento android app for a company , and was confused between the three SOAP , REST and XML- RPC , eventually went with XML RPC - really awesome and simple :D