First you use SOAP and it's nice, but after a while it's not good enough and you implement WSDL. Corporate overlords see it and suddenly everything has to be WS-YouNameIt (especially in banks and big telco). You end up in the deepest valleys of XML hell, colloquially known as WS-DeathStar.

Do to my consulting work, I've been several times through such walk.

You can have both, and you can do it in a consistent way. Not that you can make everybody happy, but it's close enough.

For example we implemented our API with both XML-RPC and REST + JSON interfaces (http://www.memset.com/apidocs/intro.html). All the methods are available and work the same way in both interfaces. There's some extra work to deal with some of the types (ie. dates in JSON), but it's not too difficult.

So we have one implementation/docs, but two interfaces to access to it.

Salesforce seems to do a good job of offering a "enterprisey" SOAP API and nice and simple RESTful API.

Edit: One of the interesting things about their RESTful API is that different versions of the API are explicitly in there as resources.

Actually, the difference between XMP-RPC and REST is not just in the format of the response, the difference is the whole approach. The way you have described (didn't go into the docs) you don't have REST at all, just XML-RPC that returns JSON. Sorry if I misunderstood.

There are two different interfaces for the same implementation. Let me stress the different part. The RESTful API uses JSON to encode the responses, but that's all.

Sorry if I didn't explain it very well, the docs are clearer though.

The point is that your RESTful API is not RESTful at all. It's just RPC using JSON. REST is an architectural style that models the interaction around data and hypertext instead of actions.

A good rule of thumb is: if the documentation mentions "methods" as anything other than the uniform ones (if you're using HTTP, that would be GET, POST, etc), then it's RPC, not REST.

Note: I'm not saying your API is bad; RPC is a completely valid model. I'm just saying it's not RESTful.

That's true, we don't use HTTP methods (PUT, GET, POST, DELETE, etc) as part of the API. In fact we treat POST/GET the same for ease of use.

EDIT: to be fair, in the docs we never say it's a RESTFul API, it was MY mistake in my first comment.