When developing an API, one of the first critical decisions every developer must face is that of Content Type. In this day and age most APIs return one or both of JSON or XML.
photo by Sean Svadilfari
Some APIs get away with one, and that’s fine, but to improve the UX of your API, you should allow the requestor to determine what data type is best for them. If you’ve read the post on API Content Negotiation, you’ll know the best way to approach content negotiation is to follow the standards.
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.
Although the REST community initially took a stance against metadata for REST APIs, a number of metadata standards have none-the-less emerged over the last couple of years, mainly fueled by the need to document APIs for their consumers.
photo by CCAC North Library
As an added benefit, the same metadata is now often used to generate code (both client and server), create test harnesses, production monitors and perform real-time validation of request and response messages (when applicable). All of these provide a foundation for an improved Quality of Service (QoS) that many enterprises require as they adopt REST for their information architectures.
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.