APIs and SDKs
Software comes in all shapes and sizes and great app ideas are many times the things we didn’t know we wanted or needed. Once that idea has been formed it can be packaged and formed into useable parts that developers all across the world can have access too. That usually comes in two form, an SDK (software development kit) and/or an API (application programming interface).
On the surface both of these seem very similar. They have the ability to help streamline your website interface by integrating data from a separate location and then that data can be presented on the front end to a consumer. This data can be in the form of product information, movie quotes, or national landmarks. If you can catalog it, there’s probably either an API or an SDK that will suit your needs.
An API is just the collection of data in a certain organizational format that can be accessed in a consistent way with certain rules. That way if new data is added, or if a new person is trying to access the data it always looks the same. A certain object has a model of data. An example would be an API of cars. You could have a specific car that will have the data of it’s “make,” “model,” and “color.” Now every car you add to the API should have that data associated with it so that if someone is trying to access it they know what data they can expect back from the API. There could be many ways you interact with that API. You could potentially ask it to send you back all cars that were made by a certain “make” or maybe you want it to give you back all the cars of a certain “color” the rules would be dependant on whoever built the API for you to use. Once you learn the rules and how to access the information you can ask for data, and the API will give it back to you in a consistent format.
An SDK can be a bit more comprehensive than an API and usually works with one to make features work. A good rule of thumb is that SDKs have APIs but not all APIs have SDKs. In addition to giving data back to a client like an API does an SDK will also have the tools and code features packaged up together to be used by someone creating an application. The code comes in the form of a library with consistent functions and those functions can be referenced within the SDK documentation. This can cut down on production time for an application because the tool and knowledge has already been packaged into a neat reusable container. You now just need to find the rules for the SDK and add that to your project.
For example you decide that you want to build an app that will let you compare prices of common items across multiple retailers. You know that every item has a unique barcode, and that is used by all retailers to scan the item and tell you their specific price. What if there was a way for you to quickly scan the item, find the barcode information, and use the barcode information to search for the item at a bunch of different retailers?
You can integrate with an SDK from a company called “Scandit.” This SDK comes with the code available to access almost any device’s camera and turn it into a barcode reader. This will allow you to get the UPC (universal product code) from the barcode. Once you have that barcode information from Scandit’s API, you can use it to search free UPC APIs to get a list of places where the item with that specific code is available for purchase. Then you could quickly compare to see which place has the best price. This was made possible by integrating the resources to access the camera, obtain barcode information from a product, and use that information to find other products. Now someone could package all of that together and use it as their own SDK and give other people the ability to use their product.
APIs and SDKs are powerful tools for people to connect data across platforms. They allow software developers to use the tools others have built to expand and grow. It is the prime example of developers standing on the shoulders of Giants.
