In this article, we will prove to you that designing an awesome web API is not that hard. You can actually develop a great API while enjoying every step of the way. The result will be a great, useful API. The key to the API design doors is down below.
API designers VS API users
When you are building a solution, you are designing for the end users. End users are not developers or programmers, but people that are probably not technically sophisticated. If you do your job the right way, the end users will get an idea about the function of the interface in front of them.
However, API designing and development is different. Here you are designing an interface directly for the programmers. Most of the times you won’t even know who they are. Programmers are surely technically sophisticated, so they would accentuate eventual flaws in your software. You should be okay with the fact that they will be critical towards your API, but this will bring you well later.
You think from the perspective of an API designer. This means that you are thinking about the function of the service you are working on. Service always provides something. API users, on the other side, think in a way of using minimal effort to get what they need from your API.
This means that you should put yourself in a perspective of the API users at the same time. Think about the questions users would ask and think about different ways to use your API, making it as simple as possible for the API users.
Here we come to a golden key. We are opening doors to a successful API design.
We are aware that this is not anyone’s favorite part, but this is the first key that leads to a successful API. Yet, using an API that is not documented is more of a torment than providing a full documentation. Users will see documentation first, so present your API well.
How do you do it?
The easiest task here is to write example requests and responses, such as elements’ descriptions too. Some tools might ease generating the generation of documents.
You need to include the use of examples, tutorials in the best case. This orientates the users understand your API better. Write as concise as possible tutorials, as they will present a skeleton for developers and point out to the right direction.
Versioning and Stability
You want to provide that you will make a change in your API whenever there is a new version out. Sure it is nothing bad to keep an old version, but if you want to stay safe – bump on a new version.
On the other side, an API needs to be consistent. Don’t change parameter names or methods, but handle common parameters and reuse the same names. This will enable consistency of data handling.
Some principles require a fairly rigid approach. This is great as it doesn’t produce any mess. Still, you should support some degree of flexibility. Don’t assume that your colleagues use the same technical preferences as you. Do a little research and glean other valuable alternatives.
This might be a cheery to the top, as easy adoption builds on all the previous ones. Here are some recommendations to ease up adoption of your API:
- If you want your API to be easily adopted, then keep it simple. Don’t experiment with crazy URL schemes, or reinvest REST, JSON, SOAP, etc. Use some tools that are already approved and implemented.
- Make the signup process simple if you are developing private source API. If you have a signup, then you want to make a direct tutorial. Also, try to make this process completely automated.
- Provide exceptional support, as otherwise, you will seem unprofessional. Lack of support, unclear documentation, and bugs will affect your API negatively. Make sure you are providing email support and address it when someone posts a bug.
Making an easily digestible, clear, useful API is not an easy task. Luckily, there are some tools that you might use in order to provide what the users will rate as excellent. If you need some help to design a rocking, best in class API, then stoplight.io might bring a solution.