The tech world is one that is constantly growing and changing. In recent years, this has been especially true for the embedded software industry. Developers are now required to start working at higher levels of abstraction—which means they have to design great APIs (application programming interfaces,) that allow software to be reused. In this blog we’ve gathered five tips for developing a killer API to help in your embedded software industry needs.
According to Nordic APIS, there are two mindsets when it comes to developing for APIs: develop for now or develop for later. The develop for now approach is the most common one, with developers creating an API for immediate use. A short-term API only focuses on existing feature sets and supports specific sets of queries. These APIs are usually made with a “this is what we need, build what we need,” mindset, rather than anticipating future needs. Because of this, often short-term APIs are not as useful as long-term APIs. Nordic APIs offered this in their blog:
Strict design for current needs inhibits potenital growth, ignoring how robust and diverse an API can truly be,”
Long-term API development not only asks, “What do we need now,” but also asks “What will we need in the future?” Planning ahead for future needs only makes an API more valuable.
Want to gain a more in-depth knowledge of APIs? Check out our free whitepaper.
While the human brain is a powerful tool, it also can only consistently remember 10 to 12 pieces of related information. Because of this, developers should aim to keep their APIs with a limited number of interfaces—usually around 10 is best. If a developer goes beyond this number, the interfaces will become difficult to remember when used together and it can make your interface look complex—making it more difficult to navigate. Tech blogger Jacob Beningo offered this:
Find ways to refactor interfaces by using control and configuration structures,”
If your plan is to make an API that can be used across multiple microcontroller vendors, then your developers should look at more than a single microcontroller datasheet. According to Beningo’s blog, “Developers should examine the same peripheral for multiple microcontrollers and make a list for all the common and uncommon features. The common features should be rolled up into the API since they are undoubtedly industry standard features while the uncommon features can be implemented in an API extension only if those features are required.”
The best APIs have logical naming conventions that allow developers to easily recognize and recall interfaces. Using cryptic letters at the start of APIs will confuse developers and question what the symbols mean. By being explicit in naming conventions, and following best practice recommendations, such as starting the naming convention from the general and working toward the specific, you can avoid leaving developers scratching their heads.
When developing APIs, following a set of best practices is key in order to meet—or even exceed—industry standards. Our best practices blog is a great start when looking to develop a new API. A few questions it is important to ask when developing an API are:
If you ask these questions, you will be in a great place to develop a killer API that is beneficial to you for years to come.