The primary appeal of a REST interface is simplicity. You don't need a proprietary library to make sense of it. All you need are a list of resources and in the case of PUT/POST operations, parameters, and the rest is handled by the nature of HTTP. No fancy libraries, no confounded WSDL files, easily-inspected responses. You can consume it using very common libraries and even roll your own with ease.
If you're always providing API access through a proprietary library, it doesn't matter if it's REST, SOAP, custom binary protocols, or whatnot.
> If you're always providing API access through a proprietary library,
> it doesn't matter if it's REST, SOAP, custom binary protocols, or whatnot.
That was exactly my thought. I was looking for reinforcement of the possibility that people will still want the entire REST interface visible and documented even in the presence of wrapper libraries.
If you're always providing API access through a proprietary library, it doesn't matter if it's REST, SOAP, custom binary protocols, or whatnot.