In a good article published yesterday on ProgrammableWeb, David Berlind shed light on an interesting emerging trend. Developers working with the wildly popular Evernote platform, wrote Berlind, seem to greatly favour SDKs over APIs. Could it be that APIs, our tech-du-jour for several years now, has already passed its best before date? Quelle Horreur!
You can guess what is coming next. I genuinely hope to be on vacation—ideally lying on a nice beach somewhere—the week some analyst declares that APIs are dead. Such rumors are always greatly exaggerated, serving more as a tired analyst device than genuine insight. But Berlind’s article highlights an important development shift that has been underway for some time. APIs, as with so many successful development styles or protocols, are settling into the fabric of the Internet. We are entering an era where we don’t need to promote APIs; they are simply assumed to be there.
But even as APIs pass quietly into the technology canon, something needs to take its place as the next great thing. This is the second coming of the SDK. If that doesn’t sound like much, you need to dig deeper, because something very important is indeed going on.
Cast yourself back into the bad old days of SOAP. In those less enlightened times, nobody ever wrote a SOAP message directly. Or if we did, it was either for our amusement, to prove a point, or because something had gone terribly wrong. The prevailing wisdom insisted that developers needed formal marshaling frameworks to do the heavy lifting of getting from object world down to the nasty wire protocol—the later being a dark place no programmer should ever venture.
It was a laudable goal, and we basically got exactly what we deserved: complex and heavy frameworks that ultimately ran exactly counter to the goal of loose coupling we had set out to achieve. All you wanted to do was write Hello, World; invariably you ended up with War and Peace.
It wasn’t a happy time.
The API movement was a response to SOAP’s spectacular failure to be accessible. The genius of REST is the recognition that integration between applications is always hard—and the answer isn’t to make this harder by adding complexity and layering unnecessary abstraction. Instead, we should leverage the simplest and most successful tools and technologies we have to get the job done. The Web is our most successful distributed computing system; let’s use it for something more important than funny cat pictures.
Ultimately, REST is an elegant solution to a difficult problem. Debugging a SOAP call with an IDE is soul destroying; debugging a REST call with curl is fun.
But there is always trouble in paradise, and APIs are no exception to this rule. APIs showed us the extraordinary lengths we can go by casting all communications onto the Web interaction mode. But increasingly I speak with developers bumping up against problems that can’t be solved with simple CRUD.
Evernote ran into this too. They needed efficient transport of large binary attachments, as well as a means of binding complex data structures. They are not alone. At Layer 7 we are seeing increasing demand for asynchronous messaging models, as well as support for streaming transports like Websockets.
This is where an SDK-approach really shines. It abstracts the detail of underlying communications, which may be unavoidably complex, and provides a native development to provide the services developers need.
But it’s a mistake to think this is just about wrappers. Wrappers were the SOAP approach—just a deterministic mapping between object side and wire side that satisfied neither. Good modern SDKs—and I resist the urge to call this SDK 2.0, which is as tired as the *-is dead device—are about enabling client developers, not throwing up roadblocks.
The crucial insight into the growing popularity of SDKs is that they acknowledge the new importance of client-side developers. SDKs focus on services of value from the client-centric perspective. SDKs are not about the server, but the service. It is a subtle, but nonetheless crucial distinction.
SDKs make the service subordinate to the client, thus inverting a hierarchy that goes back to the early days of distributed computing. SDKs are important because they suggest that while servers remain important, today it’s all about the client.
So SDKs or APIs? Both, thank you. I look to SQL as a good example of where we will end up. SQL is similar to APIs in that it’s cultural knowledge—we can just assume all developers who are any good understand it to some extent. Sometimes I use SDKs that hide the persistence layer completely behind business operations. Sometimes I use a formal data-binding framework like Hibernate. But sometimes I need to drop down and just hack out a SELECT the way I want it—and it’s fun.
So I welcome the new SDK movement. It abstracts, it’s accessible, but most important, it illustrates an important power shift in development.
Go client, young man.