Happy Easter everyone! Our little Sparky mascot here at Restlet is having fun with Easter bunnies and eating some chocolate eggs! And speaking of Easter, there’s a fun little API game where you have to wade through a maze to find some Easter eggs — I even created a little Groovy script to explore the maze!
Following-up the news about Swagger being supported by SmartBear last week, Jérôme Louvel from Restlet interviewed Swagger creator Tony Tam. Kin Lane has shared his analysis quantifying the community around the Swagger API specification. Simon Bisson wrote about managing APIs with Swagger.
Nordic APIs reminds us that SOAP is not only for your bath, and that there might actually be cases where it’s still relevant. Bruno Pedro of API Changelog fame, examines the Twilio API. And this article guides you through your API strategy pre-launch.
Arnaud Lauret describes ways to achieve API smartness, by making an API pleasant to use, with proper documentation, using hypermedia to discover what you can do with the API, with code on demand, and finally listening to API users’ feedback.
Mike Amundsen pointed at Kin Lane’s list of good examples of hypermedia APIs.
Mike Stowe gave an excellent and detailed presentation on hypermedia, the good, the bad, and the ugly.
A good point from Ruben Vermeersch is that an API is only as good as its documentation.
Betim Drenica gives his view on the ideal REST API design, covering media types, partial results, caching, security, versioning, constraints, tracing and documentation.
While I’m on the topic of Rest API design, I was discussing with the Restlet R&D team the other day about single and collection resource updates, as a whole, as a patch, the various pros and cons of different approaches, and my colleague Thierry Templier pointed me at those StackOverflow questions on updating Rest resource collections, on bulk creating or updating in a single request, and this nice article titled please don’t patch like an idiot!
With the strong tie between Rest and HTTP, I encourage you to read this long article on why HTTP is sometimes better than HTTPS.
InfoQ features an “eMag” on Web APIs, from start to finish.
On the DropBox blog, Steve Marx asks how many HTTP status codes should your API use.
Kin Lane introduces us to StreamData.io, a new service launching around caching and pushing data from APIs. Another gem from Kin with this Blockspring, to super-charge Google Spreadsheet with its API add-on.
A presentation on how to build a successful API overnight by Orlando from Mashape, with some interesting links to tools, some general API design advice, and more.
When designing an API returning lots of data, comes the question of paging results, to avoid returning too large quantities of data. Darrel Miller advocates for smarter paging. Instead of slicing the data in some simple alphanumeric order or creation order, one can think about smarter ways to page results along another axis, like geographies, categories, time slots, etc.
On InfoWorld, Paul Venezia puts APIs on a JSON diet, drawing a fine line between JSON readability and verbosity vs slim payloads to save on bandwidth and transmission time. In a similar vein, in a previous post, he also advised making APIs as lean as possible, as APIs aren’t apps.
Although these links are not new, I came across interesting REST lessons learned by Mark Seemann, like avoiding 204 responses, user-supplied data in URI segments, and hackable URLs, or like considering home and self links on all resources.