API stands for application programming interface, a concept that uses everywhere from command-line tools to business Java code into Ruby on Rails web programs. An API is a way to programmatically interact with a separate software component or source.
Unless you write every single line of code from scratch, then you’re going to be interacting with external software components, each with its own API. Even in the event that you do write something entirely from scratch, a well-designed software application will have inner APIs to help organize code and create components more reusable. And there are numerous public APIs that enable you to tap into functionality developed elsewhere over the web.
What’s an API?
An API is defined as a specification of possible interactions with a software component. What does this mean, exactly? Well, imagine a car was a software element. Its API would include information about exactly what it can perform –speed, brake, turn on the radio. It would also include info about how you could make it do those things. For instance, to speed up, you place your foot to the gas pedal and push.
The API doesn’t need to explain what happens within the motor when you set your foot on the accelerator. That’s why, if you learned to drive a car with an internal combustion engine, you can get behind the wheel of an electric automobile without having to learn a completely new set of abilities. The what and how information come together from the API definition, which can be abstract and different from the car itself.
1 thing to keep in mind is that the title of some APIs is often used to refer to both the specification of the interactions and to the true software component you socialize with. The term”Twitter API,” for example, not only indicates the set of principles for programmatically interacting with Twitter, but is generally understood to mean what you interact with, as in”We’re doing analysis on the tweets we obtained in your Twitter API.”
API as abstraction layer
When it comes to software, APIs are literally everywhere. APIs go hand in hand with one of the very fundamental concepts in computer science: abstraction. Abstraction is only a way of coordinating the complexity of a system so that complex actions can be handled in a very simple way. Think of this abstraction like those Amazon Dash Buttons, the battery worked, push-button circuit boards you may use to purchase basics from Amazon.
You order a Dash Button out of Amazon and utilize a program in your smartphone to associate it with your own Wi-Fi system, your Amazon account, and a product, sayyour favourite brand of paper towels. Subsequently, whenever you would like to purchase more paper towels, then you just press the button. The Dash Button connects to the web and sends a message to put an order on your account. A few days later, paper towels arrive at your doorstep.
Like an API, the Dash Button is a blissfully easy interface that hides all sorts of complexity behind the scenes. The ID of the item you ordered must be recovered from a database. Your delivery address must be pulled out of your account. The closest fulfillment center stocking your paper towels have to be determined, then advised to remove a product from the available inventory and pack it up. Finally, the package must be routed through some combination of airplanes, trucks, and vans along with different packages in a way that guarantees that every one of the packages will reach their destinations efficiently.
Now imagine you needed to organize each of these items as a customer. You’d never purchase paper towels because it is too complex and time consuming and you have better things to do. Luckily, the entire ordeal is abstracted away from you. There is a long, interconnected chain of computer systems and individual processes that make those paper towels appear at your doorstep, but all you have to believe about is pressing on a button.
That is exactly what APIs are similar to for developers. They require an overwhelming quantity of complexity and specify a relatively straightforward set of interactions that you can utilize instead of doing it all yourself. In any software project, you’re likely using tens if not hundreds of APIs directly, and every one of these APIs relies on other APIs and so forth.
Public APIs and API integration
APIs are a longstanding theory in computer programming, and they have been part of developers’ toolsets for years. Traditionally, APIs were utilized to connect code parts running on the exact same machine. With the growth of ubiquitous media, more and more public APIs, occasionally called open APIs, have become available. Public APIs are external facing and accessible across the online , allowing you to write code which interacts with different vendors’ code on the web; this process is called API integration.
These kinds of code mashups make it possible for users to mix and match functionality from different sellers on their own systems. For instance, if you use the marketing automation software Marketo, you can sync your data there using Salesforce CRM functionality.
“Open” or”public” shouldn’t be interpreted as meaning”free of cost” in this context. You still need to be a Marketo and Salesforce customer for this to work. But the availability of these APIs makes integration a much simpler process than it otherwise would be. (InfoWorld includes a great list of public APIs you ought to know about.)
Web services and APIs
You may remember the term w / eb services in the early’00s and think that the idea of an open API sounds pretty similar. In reality, a web service is a particular sort of open API, one that meets a fairly rigid set of specifications, such as that they be specified in Web Services Description Language (WSDL), an XML variant.
Web services were supposed to be used as part of a service-oriented architecture (SOA). As the Nordic APIs blog explains, that gave web services something of a bad name, as SOAs never quite lived up to their potential. Advances in the techniques utilized for service-to-service communications–notably lighter, more flexible REST–have also left web services somewhat behind in the world of public APIs.
REST APIs
Web services were originally designed to communicate with SOAP (Simple Object Access Protocol), a messaging protocol which transmits XML documents over HTTP. Today, however, most web-based APIs use REST–Representational State Transfer–as an architectural style.
REST was formally introduced by Roy Fielding in his doctoral dissertation at 2000. It’s a set of architectural components, layout principles, and interactions employed for building distributed systems which demand media of any kind (text, video, etc.). In its core, REST is a style of building systems that allows for flexible communication and display of data throughout the web while providing structure necessary to easily build general purpose elements.
At a REST API, a resource could be pretty much anything, but examples include an individual, a listing of tweets, and the current results of a search for tweets. Each of these resources is addressable at a resource identifier, which in the instance of web-based REST APIs is usually a URL, for example https://api.twitter.com/1.1/users/show?screen_name=twitterdev. When an application requests a resource with the identifier, the API delivers the current representation of the source to the application in a format which the application can consume, such as a JPEG image, HTML page, or JSON.
One of the big differentiators of REST is that it entails sending data to the requesting application. While this provides great flexibility, allowing the program to do whatever it wants with the data, it comes at the price of efficiency. Sending data on the web for processing is rather slow in comparison to performing the processing where the data resides and then sending the results.
Obviously, the problem with the”effective” strategy is that systems hosting the data would need to understand what applications want to do with it ahead of time. Thus, so as to build an API that’s overall purpose usability and flexibility, REST is the way to go.
API examples
There are plenty of public APIs out there for you to socialize with, many from industry behemoths. The ability to access some stage company’s code programmatically through an API is the thing that makes them a stage, in essence. Some prominent API examples include:
Google APIs, which permit you to connect your code to the total selection of Google services, from Maps to Translate. APIs are so important to Google that they acquired Apigee, a leading API management system.
Facebook APIs, which allow you to programmatically access Facebook’s social chart and marketing tools. (The company has been restricting precisely what user data you may access via these APIs in the fallout from Cambridge Analytica and other scandals.)
To really get a feeling of how APIs work, let’s do a deep dive into 2: the Java API, that Java programmers use to interact with the Java platform, and also the Twitter API, a public API which you would use to interact with all the social network service.
The Java API
The Java API is a library of software components available”from the box” to anyone who has set up the Java Development Kit. These elements implement common jobs and generally increase productivity because programmers don’t need to start from scratch every time. Among the basic elements used in applications is something known as a List, which, as you may expect, keeps track of an inventory of items. The Java API defines exactly what you can perform using a List: add things, sort the list, determine if an item is in the record, etc.. It also specifies how to perform those activities. To be able to form the List, you need to specify how you want the List sorted: alphabetically, numerically descending, brightest to dullest color, etc..
The Twitter API
The Twitter API is a web-based JSON API which enables developers to programmatically interact with Twitter data. Unlike the Java API, which is included in the Java Development Kit, the Twitter API is a web-based API. It must be retrieved by making requests across the Internet to services that Twitter hosts.
Having a web-based API such as Twitter’s, your program sends an HTTP request, just like a web browser does. But instead of the answer being delivered as a webpage, for individual understanding, it is returned in a format which software can easily parse. Various formats exist for this purpose, and Twitter utilizes a favorite and easy-to-use format named JSON. (If you’re not familiar with JSON, you may want to devote a couple of minutes reading up on it here.)
One of the basic elements in Twitter is that a tweet. The Twitter API tells you what you can perform with tweets: search for tweets, produce a tweet, favourite a tweet. Additionally, it informs you how to perform those actions. To search for tweets, you want to specify your search criteria: terms or hashtags to search for, geolocation, speech, etc..
API design
API design is the process by which the”what” and the”how” of an API are formulated. Much like anything else that may be generated, varying amounts of consideration and care are put into API design, resulting in varying levels of API quality. Well-designed APIs have consistent behavior, take their context into account, and keep the needs of their users in mind.
Consistent behavior within an API greatly impacts the rate at which it could be learned along with the likelihood of developers making mistakes when using it. Generally, APIs that perform similar actions should behave similarly, irrespective of their technical differences. For an example of an inconsistent API, let’s look at the two ways to add an item to a List in Java:
Though the two methods of adding things to a list do exactly the identical thing, their return types (boolean and emptiness ) are different. Developers using this API have to keep tabs on that method yields which type, which makes the API more difficult to understand along with its usage more mistake prone. It also entails that the code that uses these methods becomes less flexible, because it has to change if you want to change the way you’re incorporating elements.
Taking context into consideration is another sort of consistency, although it has to do with factors external to the API. A excellent, non-software example of this is how the principle of the road–right hand traffic or left hand traffic–affects car designs for different countries. Car designers take that ecological variable into account when locating the driver seat on the ideal side or left side of the car.
In API design, taking context into account usually means that you’re adhering to commonly accepted best practices and taking inspiration from different APIs your users will likely be familiar with. Say you’re building a library which provided a new sort of List to a Java program, maybe one that was made to work specifically with very large lists. The API of the List should probably incorporate an add method that behaves in precisely the same way the Java List include method functions. This way, users may easily adopt your library because they already know how to utilize it.
Understanding your customers and keeping their needs in your mind is of the utmost importance in API design. Your API will have happy customers if you understand their pain points and help them prevent that pain. For the identical reason, you may opt to break with other rules of good API design. In the event that you were composing a web API, the de-facto standard today is to use JSON as the interchange format. However, if your API is going to be serving scientific users who will be retrieving huge amounts of data, JSON is going to be overly verbose and cumbersome to serve them well. Because of this, you may choose to utilize a binary format such as GRIB, though it’s an extremely rare choice in the overall sense.
APIs are a basic part of software design and they exist at every level of their software stack. They provide a way to identify and handle abstractions by telling us exactly what we can do with software components and how we could do it. Well-designed APIs support effective, fluid, and effortless adoption and use, while poorly designed APIs tend to cause headaches every time they’re used.
API growth
Ready to start in creating your own APIs? Check out InfoWorld’s handy listing of no-cost tools for API development, including API designers, analyzing and debugging tools, gateways, and full-blown expert API services.
