This thread remembers me of a discussion I have with a friend about this. What are the advantages/disadvantages of using a web API vs. language APIs?
The good points of a language API: as a service consumer, if there is an API for your language, it is far easier to consume the services than with a web API (if it is well designed of course)
Bad points:
a) As a service provider you typically need to implement several libraries (JS, Java, Ruby, Python), maintain them all and distribute them.
b) There is the risk you don't focus on the HTTP/REST details, so you end with an implementation that doesn't play well with the web. Pretty easy to get an RPC design in your library that doesn't translate very well to REST.
c) If you don't provide a web API, or document it, the language API is effectively the only way to access your services, and your consumers are immersed in a vendor lock in scenario.
If you go for an only web APIs approach, you solve most of the problems of a language API. But in my experience only a few developers understand REST and HTTP in an effective way, so your potential base of consumers is lower. Of course there are frameworks, but if a framework does not support well the concept of hypermedia, it won't be very effective consuming hypermedia apis. That's one reason why we don't see a lot of hypermedias APIs nowadays. The point of having an API is making easy for people to consume your services, and a lot of guys think this hypermedia/REST approach is too confusing.
Perhaps code on demand could be a good compromise?
Cheers,
Enrique