Globalizing APIs is hard. I’ve posted before about some of the pitfalls of dates and times in APIs in The 5 Laws of API Dates and Times, as well as content and currency localization in How to Localize Your API .
One area that I did not get into was how timezones can play a role when a specific time and location are in play.
Simply put: you cannot tell what the UTC offset of a given date+time will be, unless you know precisely where and when it will be. As such, this becomes the defining line for when we should supply timezones.
It will be the biggest conference in the Nordics ever that focuses just on the technology and business impact of APIs. The goal is to gather people from Sweden, Denmark, Norway and Finland as well as cross-industries to learn from each others experiences and to hear from the best.
Pivotal Tracker just announced the availability of their API V5 in public beta, starting August 16, 2013. The launch is justified because the application itself has run against the new API version for a long time now.
photo by John Fischer
The new API introduces several improvements, like the ability to get access to all project data, including epics. They also say that everything in and out of the API is now JSON encoded but the activity Web Hooks still POST information using XML.
Evernote recently announced that they will enforce API rate limits starting today (August 14, 2013). They don’t specify what the limits are but they say that a “reasonable use of the API should not cause an integration to hit the limit”.
photo by Justin Ennis
Although this enforcement will only affect non-production applications for now, you should evaluate your code even if you have a production API integration, since rate limiting will also affect these applications starting November 1, 2013.
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.