Tictail, a Swedish e-commerce platform that manages over 24,000 stores spread across 110 different countries, launched their API on September 16, 2013. Because Tictail’s main focus is simplicity of use, they decided to offer developers the same tools they use internally to build this new platform. According to Carl Waldekranz, Tictail CEO, they “want developers to have that same opportunity as [the company] continues to grow internationally.”
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.
What exactly is Content Negotiation? According to Wikipedia it’s “a mechanism defined in the HTTP specification that makes it possible to serve different versions of a document at the same URI, so that user agents can specify which version fit their capabilities the best”.
photo by JD Hancock
So, it serves two purposes: (1) making it possible to have different versions of the same response, and (2) letting clients specify which version they want to receive. Usually, this technique is applied when there are several types of user agents consuming the same HTTP resource but, because they have different rendering capabilities, they might ask for different content types.
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.
One of the biggest difficulties developers can have when writing code that talks with an API is dealing with errors and exceptions, and translating those errors into something meaningful for their applications.
photo by Bent Jensen
Because APIs are based on different technologies and libraries, error codes are often inherited and do not make sense to whatever framework the consumer is using. Even worse is when those error codes and messages are simply passed through to the end-user without any manipulation by the application.
So, how can you make sure that all your API consumer understand your error codes and can handle them properly? If you’re offering a REST API, consumers expect your endpoints to behave like any other HTTP endpoint, so a good start is to simply follow the standards.