If we want to create the best applications, we can currently find many articles and information related to the UX (User Experience), which I mention in my previous article, this experience consists of all the interactions that a user can have with our application , since the download until it closes, you should try to make it intuitive and easy for the user to navigate the application and perform the functions that it needs.
The platform we develop must have a specific function to better meet the needs for which it was designed, however it is very likely that it ends up generating valuable information for different purposes and in turn the information we require and may already be specified in other platforms. In order to make a communication between our platform and others it is necessary to use tools called API's.
The api's define what user information is shared with other platforms and are useful since, from them, other developers can create different applications that complement or expand the functionality we want to offer. If we want it to be attractive for developers to implement our API it is necessary to consider the DX.
The DX (Developer) is very similar to the UX, only that it refers specifically to the developers who try to integrate our service with theirs through API's.
These are some points you should consider to get a better DX:
- The most important point is to have all our platform well documented, make sure that all functions are still valid, so it is advisable to implement unit tests, and if necessary, version our API, so that older applications can continue to benefit from our information
Create an SDK or set of officially libraries
- It is not enough just to write functions about the calls to our api, if we already have a clear definition of our objects the types and formats that our application uses, other developers may well benefit from these definitions and it becomes more relevant if these are written in a programming language that they already use.
- It is also advisable to create an open source repository to facilitate its maintenance, since the same community can correct and test if there are errors.
Use industry standards as REST
- We could write our apis in any way, although we usually fall into the error of writing our apis in the same way that users browse our site using very long queries in our urls that end up being illegible for a developer. REST has been adopted as the standard to compensate for this problem, in such a way that more experienced developers expect our API to react in a certain way when presented with different requests.
Use examples in the most popular languages
- The first thing we want to do when learning to use a new API is to be able to run some test, which is easier if we offer these examples, and also in languages that are likely to be those used by our users, we must also try that these are current and functional. A good strategy for this is to include them in an open source repository such as the SDK where the community itself can expose, correct and develop them.
Easy to understand and use
- This goes directly from the documentation, also the names of the functions and modules should be easy to understand and represent the objects that you want to show.
Easy to try
- One of the clearest examples for this point is the Graph API Explorer an API tool that allows you to send requests to the API from the same portal, which allows you to see the information as it will be sent to you and the necessary permissions to access it. , in addition to the possibility of exploring other functions that you could implement.
Easy to get help
- This is another reason why it is advisable to have an open source project, where you can send any problems that may arise and that the same community can support each other, it is also possible to include links to platforms such as forums and to attend the related questions in stackoverflow