Is Evernote's RESTless API Approach A Model For Other API Designs?

Not to be confused with the next version of Amazon's EC2, "EC3" stands for "Evernote Conference 3"; Evernote's third annual conference which took place last week in San Francisco, CA. Just the mention of the word "Evernote" brings a gleam to the eyes of the Evernote-faithful. For many, it is hands-down the one killer app that they cannot do without. As the company's CEO Phil Libin likes to say, Evernote is like having a second brain. The more habitually it is used to keep notes (typed or handwritten), lists, documents, recordings, images, and clippings from the Web, the better a second brain it becomes; a second brain that runs on pretty much every major Platform as well as the Web.

For third party developers looking to capitalize on the popularity of Evernote, the company offers an API.  But Evernote is not a classic API provider like many of the other API providers covered on ProgrammableWeb. According to Evernote's vice president of platform strategy Seth Hitchings, developers can interact directly with the API, but most don't. Instead, they work through one of Evernote's software development kits (SDKs). While Evernote is not the only company to take the SDK route, the company has certainly set itself apart in terms of its commitment to include as many developers as possible. The list of platform-specific client and server-side SDKs offered by Evernote is impressive; ActionScript3 (for Flash), Android, Mac OS X, C++, C#, iOS, Java, JavaScript, Perl, Ruby, Python, and PHP.

So, why produce and support so many SDKs instead of supporting a handful of methods across a few RESTful APIs? Hitchings concedes that compared to the RESTful APIs, developers have to endure a bit of a learning curve to make use of the SDKs' core functionality; to create, read, update, search, and delete Evernote content. But then again, according to Hitchings, Evernote is a special needs case because of how Evernote must efficiently keep so much data in synch between all the clients and the Evernote cloud.

Seeking the least compromise to data-transfer performance, Evernote needed a solution that could shuffle large quantities of data with minimal overhead. Despite its superior efficiency over XML, REST still wasn't good enough. Instead says Hitchins, Evernote turned to a technology called Thrift that was originally developed by Facebook. According to a blog by Evernote CTO Dave Engberg dating back to May 2011, among the many reasons for the move to Thrift was its binary efficiency:

"If we specify a ‘binary’ data field holding 1MB of data, that will marshal as 1MB on the wire."

Now one of the many open source projects at the Apache Foundation, Thrift's code-generating ability to write-once-and-deploy-to-many is also the reason Evernote is able to offer SDKs for so many platforms. This ability to create native code for all of Evernote's supported platforms was another of Thrift's unique selling propositions that attracted Evernote to the technology.

According to Hitchings, "[Thrift] was super efficient for us in terms of moving data over the wire. With more data comes more time. Efficiency is really important for us. But so is great compatibility across platforms.  With Thrift's code generators, we got the client side code we needed for iOS, Android, Mac, Windows, C#, etc."

Clearly, Thrift is getting the job done for Evernote's developer community thus raising the question of how well-suited it and other non-REST alternatives (Apache's Avro is another) are to other organizations contemplating the publication and usage of APIs.  When it comes to that question regarding Thrift, Engberg was quite prescriptive in the aforementioned blog:

"If your application had the exact same requirements as Evernote, then Thrift may be a good choice. If you don’t have a complex data model with big binary attachments (requirement #2), then the answer isn’t so clear.

Web services with simpler data models tend to use simpler REST protocols with ad hoc XML or JSON data marshaling. This approach means that simple operations are really simple to test and implement. If I only need to do two things with Twitter’s API, I can test them manually from the command-line with CURL/wget and then hand-roll the code into my app with printf/println/regexps/etc.  This means that there’s a very low bar for third party developers to get started with this type of API.

Our Thrift API imposes a higher burden on developers, who need to get all of the transport layer details done and the Library dependencies into their app before they can do any testing at all."

For many API providers, the low barrier to entry for developers is an important factor to getting market traction. Evernote's 30,000-strong developer community suggests that the burden might not be so overwhelming.

But if the 30,000 number in any way suggests there could be a vibrant array of third party applications, users of Evernote would be hard-pressed to find them. Not only does Evernote's App Center (formerly "The Trunk"; its version of an app store) oddly lack a way to search for apps, only a few hundred apps are listed in it. When asked about the disparity, Hitchings noted that the App Center is unlike other app stores in that all of the applications are curated by Evernote before being listed. When asked how many unlisted third party Evernote applications could be floating around in the wild, Hitchings didn't know.

Regardless of how many developers are truly engaged with Evernote's SDKs, there are enough that Evernote is getting the sort of feedback it needs to improve its SDKs. Hitchings told ProgrammableWeb that the developer relations team spends a lot of one-on-one time -- especially with non-domestic developers -- to make sure its developer program is always on the cutting edge of what Evernote's global users need. In his EC3 keynote, Libin said that the majority of Evernote's 75 million users are outside the US. Hitchings also said that the Evernote's SDKs (which can be found on GitHub) are often forked by third party developers. A fair amount of that code gets pushed back to Evernote where it's considered for inclusion in future releases.

Are SDKs (backed by a technology like Apache Thrift or not) a viable route for other API providers to consider in lieu of REST? Do benefits such as Payload efficiency and cross-platform support outweigh the time to market and ease of developer adoption? These are critical questions that are highly situational, but that should not go unanswered as a part of any API design project.

By David Berlind. David is the editor-in-chief of You can reach him at Connect to David on Twitter at @dberlind or Google+, or  friend him on Facebook.

Be sure to read the next API Design article: The Emergence of API-First Development