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.
I have been working as a User Experience designer at CloudWork for the past 6 months and I’ve faced many challenges and opportunities while building an easy to use product that automates business processes and synchronizes cloud-based applications.
The UI and UX of the application was very easy to create compared to the actual UX of the service. The uncertainty and the number of dependencies for creating a successful integration between cloud applications is so high that it seems almost impossible to guarantee the Quality of Service.
The main issue is the lack of standards. Each application has a different API, different logic, different nomenclature. Even applications of the same class, e.g. CRM, are completely different beasts. This makes it really hard to guarantee the same solid integration between CRM A and APP X compared to CRM B and APP X. This can make creating a consistent User Experience very difficult.
HTTP API authentication has evolved through many forms over the years. As so-called RESTful APIs gained popularity, a variety of methods sprung up: key passing, plain-old HTTP Basic Auth, OAuth 1.0, OAuth 1.0a, OAuth 2.0 (and it’s 40 revision) and some less-common custom schemes. With the OAuth 2.0 specification finalized, things are finally starting to settle down and coalesce around a single auth mechanism. For publicly-available APIs, OAuth 2.0 should be on your list of requirements.
Let’s say you’re building your first API. Be it public, private, or some hybrid thereof, don’t be surprised if your first defect is date/time-related. Do not underestimate how much trouble you can get into when it comes to handling date and times. Here are some tips which might keep you out of this potential future.
According to ISO 9241-210, User Experience, or UX, is “a person’s perceptions and responses that result from the use or anticipated use of a product, system or service”. Additionally, Wikipedia has a broader definition, covering many aspects of the way users interact with a system:
[UX] involves a person’s emotions about using a particular product, system or service. User experience highlights the experiential, affective, meaningful and valuable aspects of human-computer interaction and product ownership. Additionally, it includes a person’s perceptions of the practical aspects such as utility, ease of use and efficiency of the system. — bolds added by me
So, if APIs are, by definition, Application Programming Interfaces, API User Experience can be defined as follows: