When SDKs Are Better Than APIs

Guest Author, October 4th, 2013

Scott Morrison is Chief Technology Officer at Layer 7. You can follow him on Twitter as well as on his blog.

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.

Tags: Issues
Both comments and pings are currently closed.

5 Responses to “When SDKs Are Better Than APIs”

October 6th, 2013
at 4:40 pm
Comment by: Mike Borozdin

So what are the SDK’s or not what you recommend? Evernote? What else?

October 6th, 2013
at 11:06 pm
Comment by: Chess Cardigan

Interesting post. What it comes down to, in my opinion, is that the simple case should be simple. The problem with SOAP was (is) that the simple case wasn’t simple. WS-* attempted to provide general frameworks to solve too many problems at once, which necessarily made it complex. Each REST API on the other hand, solves one specific problem, making the simple case simple. But the tradeoff is each REST API is different, there’s no one standard. And the complex cases, which made WS-* complex, do come up, and at that point the RESTful solution is no longer simple. Providing SDKs makes sense. No doubt the current push for REST based standards will intensify. In 5 years time we’ll be back to where we were with WS-*, and the cycle will be complete.

October 7th, 2013
at 12:45 pm
Comment by: David Berlind

Mike — can you clarify what exactly you’re asking for?

Chess — that’s a really interesting point that things could come full circle. Would you care to elaborate in a full post on ProgrammableWeb? Let me know!

David Berlind
editor-in-chief
david.berlind AT ProgrammableWeb DOT com

October 7th, 2013
at 3:30 pm
Comment by: Scott Morrison

@Mike Borozdin:
A good example of the SDK-focus I write about here is can be found in the MBaaS space (Parse, Kinvey, StackMob and many others). There are certainly APIs doing the integration underneath the hood, but the focus of these companies is on providing native SDKs (ie: iOS, Android, JavaScript, etc) that provide useful common services for client-side mobile developers.

@Chess Cardigan:
Great point—making the simple stuff simple might be good for the majority of use cases, but the model can work against you when you run up against the hard problems in communications. The thing that encourages me about the trend toward providing SDKs is that they are designed with client developers in mind, as opposed to generated from API implementation. Good SDKs are there to provide a service to client-side developers first and foremost, without being constrained by the existing capabilities of any single API underneath.

No question SDKs are more work to maintain than a simple API endpoint (especially if you are targeting many platforms, which most modern SDKs seem to do). But in the end the goal should be to drive use of a service, and the best way to achieve this is to offer something useful, and to make it simple to use.

October 8th, 2013
at 7:52 am
Comment by: David Berlind

It seems to me that SDKs could also offer a layer of insulation from changes to an API.

Follow the PW team on Twitter

ProgrammableWeb
APIs, mashups and code. Because the world's your programmable oyster.

John Musser
Founder, ProgrammableWeb

Adam DuVander
Executive Editor, ProgrammableWeb. Author, Map Scripting 101. Lover, APIs.