Before we begin working through lessons and coding, let's take a moment to discuss what an API is, and how it is different from a the database-driven apps that we have already created.
API stands for Application Programming Interface. It is not a database or server, but an access point for an existing application.
Imagine the following scenario: You (as in, your application, or your client, this could be a web browser) wants to access another app's data or functionality. For example, perhaps you want to access all Twitter tweets that mention the
#epicodus hashtag and show them on your website.
You could email Twitter and ask for a spreadsheet of all these tweets. But then you'd have to find a way to import that spreadsheet into your application; and, even if you stored them in a database, as we have been, the data would become outdated very quickly, as in, immediately.
It would be better and simpler for Twitter to provide you a way to query their application to get that data, so that you can view or use it in your own application. An API brokers access to a different application to provide functionality or access to data.
When people speak of "an API" they sometimes overgeneralize and actually mean "a publicly available web-based API that returns data". The API is not the database or even the server, it is the access point for the server.
Large social media companies frequently make their aggregate data available to the public, but APIs are also maintained by government organizations, conferences, publishing houses, software startups, fan groups, esports leagues and even individuals. APIs can be used to share anything from social media content to trivia questions, rankings, maps, songlyrics, recipes, parts lists and more.
This week, we will learn more about building a data model, RESTful routing and more by building a simple API that returns information about restaurants in the area, similar to services like Yelp.
In week three, we created a simple To Do List project that stored tasks and categories in a H2 powered Postgres database, then queried that database to display
Tasks on our page. Isn't this basically what an API is?
Yes and no. While we were creating routes with route handlers to perform CRUD operations on our data, we were still just passing that data around as Java objects, mostly, and handling everything internally. We were pulling user data to create objects, and saving them to our database. But we were not making the raw data itself available to an outside user. When a user visits a route in their browser, they are presented with data embedded in a view layer - the .hbs templates we created that then get translated into HTML, with a bunch of styling. The data arrives to the user as HTML, not as data that can be parsed by a client app and then used to perform logic or data visualization with, for example.
Our API project in week four will only have a minimal client side that receives and handles data, while the majority of the work will be happening on the server side that issues the data.