Introduction to APIs
APIs (application programmable interfaces) most simply allow different programs or machines to work together. They are able to call each other to give and receive information necessary to allow the software consuming that data to function properly. By outsourcing some of the functionality of our programs to APIs, developers are able to simplify their process and focus on making the product itself. We encounter these all the time when we download a new app on our phones and it asks for permission to access another application on your phone, like the map being used to provide location services, or your camera granting access so you can use funny filters on Instagram. Even the weather app is using an API to get the information it's giving you: there isn't anyone who works for Apple going around placing temperature gauges all over the planet to gather that data; it's using The Weather Channel's API to receive it and then passing it along to you. If you buy smart home features like thermostats, lighting, or security products and give them permission to access your smart speaker so you can tell your home robot assistant to make it cooler in here because it's July in New Orleans and we're melting, that device is using Alexa's API to share information back and forth.
A developer utilizing an existing API to build out the functionality of their app is wisely outsourcing some extra complexity. You don't have to understand everything going on under the hood of a car to drive it using the pedals, steering wheel, shifter, and instrument panel. You are provided with an interface that makes it user-friendly and relatively easy to operate. If you had to build the engine and transmission every time you needed a new vehicle, you might just have to start taking the bus and give up driving altogether. If every aspiring developer had to create every complicated feature of their app from scratch each time, we'd have far fewer developers at all with the massive skills required to make our cool new playthings.
RESTful APIs
REST is an abbreviation for 'representational state transfer.' It's a set of rules for a particular approach dictating how software components will talk to each other, what kind of messages they will send, and how they will handle these requests. It is actually just one possibility for internet architecture, but has become the most widely-used thanks to its many benefits over competing styles. The concepts REST embodies are as old as the internet itself, but it was packaged up and formerly introduced in 2000 by computer scientist Roy Fielding in his doctoral dissertation at UC Irvine called Architectural Styles and the Design of Network-based Software Architectures. It's essentially a distilled collection of internet architecture wisdom guiding best practices for implementing HTTP protocol. REST is an alternative to SOAP (simple object access protocol), created by Microsoft in 1998, which only allowed XML data formatting.
REST allows several data formats, most notably JSON, which is easy to understand, supported by all common browsers, and uses little bandwidth, making it the standard for data transfer and thereby elevating REST's success. REST also allows for caching static information (components that don't need to be changed often), allowing applications to run faster.
REST enforces HTTP protocol for sending messages over a network, using standardized keywords like 'GET', 'POST', and 'DELETE' for receiving, creating, and getting rid of information, making requests explicitly clear. In a current assignment for Operation Spark, we are working on a client side project that accesses data stored on an external server. Here's a partial example of how we could make a request in our code:
create: function(message) {
$.ajax({
//communicate with the parse API server.
url: Parse.server,
type: 'POST',
data: JSON.stringify(message),
contentType: 'application/json'
}
};
This snippet is using the 'POST' keyword in a function that will create messages.
REST guidelines specify that relations between the client and server are 'stateless'- there shouldn't be a stored record of prior exchanges between the two, and each individual request must be handled only with the information that accompanies it at the time of request, ensuring efficiency and speed. Additionally, the client and server should be loosely-coupled entities, allowing each to be expanded or enhanced independent of the other.
Conclusion
The history of APIs isn't long, but its impact on technology development is significant. Salesforce was the first company to market its own API in 2000, a part of its signature "Internet as a Service" package. In the next few years, E-Bay and then Amazon developed their own APIs, expanding their market reach by allowing other sites to access them. Soon after, in 2004, Flickr released a photo-sharing API giving users the power to embed images stored on Flickr's servers into their own websites and blog posts. Then came Facebook and Twitter with their APIs in 2006. Now virtually anyone has the power to create and use helpful 'widgets' and APIs across applications, increasing the functionality of their program and its ease of use for both developer and end user. Adhering to RESTful principles when creating and using these APIs allows for greater flexibility and efficiency for everyone involved.
Top comments (0)