May 30, 31 & June 1, 2013 in Madrid, Spain
APIdays Mediterranea is the event that will get together business, projects and people from the API ecosystem in Southern Europe and Mediterranean countries.
May 30, 31 & June 1, 2013 in Madrid, Spain
APIdays Mediterranea is the event that will get together business, projects and people from the API ecosystem in Southern Europe and Mediterranean countries.
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”.
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.
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.
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.
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.