The biggest Nordic APIs conference to date was held in Stockholm, Sweden 18-19 September, 2013. As one of the organizers I am proud to say everything went very well and that we did what we set out to do – which was to create a place for the API community in the Nordics to meet in person.
During the conference there were a few themes that emerged – that APIs are about more than technology, that the security stack is maturing and that we have a strong API community.
Back in 2006, Jeff Lindsay proposed a different way of consuming Web resources that would eliminate the need for constantly polling APIs for changes. This new pattern was called webhooks and has since been adopted by companies such as GitHub and Google.
REST and webhooks are two sides of the same coin. In “Web Hooks and the Programmable World of Tomorrow“, Jeff Lindsay, October 2008
The main advantage of the webhooks pattern is that your application doesn’t have to make periodic calls to APIs while it’s waiting for changes. Instead, APIs will call your application on a specific endpoint informing that something interesting has happened. What’s missing is a way to programmatically tell APIs that you’re interested in receiving calls and registering endpoints.
The first implementable draft of HTTP/2.0 was released on July 8th by the HTTPbis working group of the IETF. The 2.0 version of HTTP is based on the SPDY protocol developed by Google — in fact, the initial draft was a copy of the SPDY specification as a base for diffs.
Photo by Jeffrey Beall
HTTP/2.0 is intended as an alternative to HTTP/1.1, rather than deprecating the old version. There is good reason for this: The new version feels similar to the old, but there are important differences designed to enable more efficient network communication.
Since Google’s announcement of Glass people have been wondering about the possible applications that can be built on it and how it might increase one’s productivity. Well, your wait is over now, because Google has recently released the documentation on how to interact with Glass through their Mirror API.
According to the documentation, the Google Mirror API “allows you to build web-based services, called Glassware, that interact with Google Glass”. Even better is the fact that this functionality doesn’t need that you run any code on Glass itself, since all interactions are done via RESTful endpoints.
At a first glance you might think that offering an API method that returns information about your application users might not be a good idea. With the increasing usage of APIs for business related purposes you might fear that you’re giving away precious information about your customers.
photo by The Wide Wide World
But think again. If you give the right amount of information, applications built on top of your API will be able to offer a better service to your users. Your final user will have a better experience and that might turn out to generate more business for you.