Should Cloud APIs Focus on Client Libraries More Than Endpoints?

Cloud APIs are all about the endpoints: some services follow the current trend of providing a RESTful end point, others use older protocols such as RPC or SOAP, some use newer - push focused - endpoints like WebSockets or HTTP Streaming, others may offer a number of different endpoints to meet different requirements and some just use what seems to be best for a specific job which might mean not strictly following protocol rules. But is providing an endpoint to a service alone good enough? Should a developer really have to care about how a service is built or accessed when they can use a client library?

This post was very much inspired by William Vambenepe's blog post called Cloud APIs are like military parades which focuses on the current trend of REST APIs but it also covers some interesting questions and one very key one:

How many developers actually directly access an endpoint and how many access a service through a library?

So, should cloud services just be providing endpoints and relying on community, open source and developers to build libraries that make access to their service easier? Should they just provide samples or small helper libraries? Or should a library be provide by the cloud service vendor and be considered a key part of that service?

There may not be right or wrong answers to these question, it may very well depend on the complexity involved in using the service API.

A look at the all time most popular APIs used by mashups in our API directory unsurprisingly lists Google Maps, Flickr, YouTube, Twitter, Amazon and Facebook. The most popular mashups listing also confirms this with a heavy focus on the mashups using mapping APIs.

Mapping APIs are quite complex due to the UI aspect of the service and the majority of libraries are provided by the cloud service vendor. Twitter has developed a large array of libraries built by an "ecosystem" of developers, Facebook provides a suite of SDKs and Tools, Flickr provides API Kits, the YouTube API consists of libraries for visual-oriented functionality and raw access to a data API and finally Amazon offer SDKs for access to AWS APIs and provide code samples for accessing their product advertising one.

Big cloud API players are clearly making an effort to give developers a running start when using their APIs. In the majority of cases some raw API access is available but samples, SDKs and libraries can be found in abundance and have quite frequently been developed by the company itself.

So, do cloud services offer API endpoints just to meet the needs of a very small percentage of developers who want to make raw calls to an API? Do they do it in order to enforce good development practice? Or is the main benefit that it encourages developers and open source advocates to get involved with a service and built a community? What do you think?

Photo by Kevin Dooley

Be sure to read the next Mapping article: Factual Now Covers 27 Countries, 30 Million Business Listings


Comments (9)


Hopefully not. I'm optimistic that there's a middle ground between human-readable-only API documentation and the complexity of ws*.

As a matter of fact, I'm certain of it, and I'm convinced that it's only a matter of time before we have something of that nature. Non-standard human-readable documentation leads to higher than necessary development costs. As web-accessible APIs continue to move from novelty to business necessity, economic pressure will dictate the acceptance of such a standard.

I'm not complaining, too much, in the meantime. My company is currently able to capitalize on this lack of a standard - we generally understand the human-readable documentation and program to it quickly, but the cost of integrations would fall significantly if we could remove some of the need for the human component from them.

Again, REST, implemented properly (as it rarely is), may be a good solution here.


We need a generic OpenApiLib that support the basic access functionality for each API and APIs should be designed to fit such a library.

As developer, I don't want to use 5 libraries to access 5 apis, especially if the the design of those apis is very similar.

And I don't want to work low level and send http requests and parse the contents by my self. That would mean to build your own library for a specific api.

With respect to Philipp's comment, that's why I'd like to see more developers investing some time in YQL. If developers who produce APIs also take some time to provide a YQL data table definition and contribute to the project then people can make use of, and combine APIs across disparate services through a single (YQL) API.

>> Comment by: Kurt Milam

>> I’d love to see the big players settle on a simple, machine-readable standard for describing API endpoints.

And then wouldn't that devolve into WS* all over again?

When it comes to building enterprise API integrations for customers, my company prefers to connect directly to the API endpoints. We've built a powerful API connector library/framework that allows us to quickly connect to just about any API endpoint, and frees us from having to include 5, 10 or even more separate libraries from different providers in our solutions.

Some problems with using native libraries (especially for enterprise integrations, where you may be working with 10 or more services):

- Each library is coded by someone else, and will most likely have its own quirks - you're relying on someone else to do a good job of writing the library, and you're stuck with the quirks if they don't

- Some libraries only run on top of large frameworks. If you're not already using the framework in your application, it's questionable whether it makes sense to include it in your application just to access a library's features

- Managing an application with 10, 20 or more libraries can become complex over time - keeping libraries up-to-date as new versions are released, etc.

- We've seen cases of libraries that are not kept up-to-date (by their authors) with the APIs they connect to - quickly coded, released and not maintained/supported afterwards, just so the provider can say "we've got libraries" to prospective customers

Our framework allows us to easily model complex, integrated interactions, stacking calls to multiple APIs with very little code. For example, we have one integration that makes nine different stacked calls to three different APIs, all in 89 lines of code.

If you just need to integrate with one or two services, and you're not too concerned about whether the libraries you use will be kept up-to-date, libraries are probably an OK way to go. When you start connecting to more and more services, they can become a liability.

The problem with connecting to the endpoints? It's a pain that so many of them are only documented in human-readable format. I'd love to see the big players settle on a simple, machine-readable standard for describing API endpoints. Proper implementation of REST (self-describing) might be the way to go here.

[...] Current events - French Stanford Student AssociationYou can subscribe to our Google Calendar by clicking here. Here is the calendar for our current events. Click on each event for more details including location. ... Access Doc Wyse Transforms Digital Signage, In-Store Advertising And Retail Kiosks With Cloud Client"> [...]