Now that you know what an API is, let's talk about what makes up a REST API. We'll be using REST in this course because it is the most popular. It is one of the most logical, efficient, and widespread API creation standards. And according to Cloud Elements’ 2017 State of API Integration report, 83 percent of APIs now use REST.
Understand the Advantages of REST
Representational state transfer (REST) is a set of architectural standards or guidelines that structure how you communicate data between your application and the rest of the world or between different application components.
RESTful is used as an adjective to describe REST APIs. All REST APIs are a type of API — but not all APIs are RESTful!
RESTful APIs rely on HTTP to transfer information — the same protocol that web communication is based on! So when you see the http in the beginning of a URL, like http://twitter.com — your browser is using HTTP to request that website from a server. REST works in the same way!
There are six key architectural guidelines to using REST APIs. Let's check them out!
#1: Client-Server Separation
One of the standards of REST is a rule called separation between client and server. We spoke a little bit about clients and servers in the last chapter, but let's flesh out some of the details.
A client is a person or software that uses the API. That could be an application, a browser, or a piece of software. For example, as a developer, you might use the Twitter API. A client could also be a piece of software or a browser such as Chrome, Safari, or Firefox. When a browser goes to twitter.com, it calls the Twitter API and uses the data from the API to view the latest tweets.
Meanwhile, a server is a remote computer able to grab data from the database, manipulate it if necessary, and hand it over to the API, like this big computer in the middle:
Typically, there's a separation between the client and the server. This separation enables the client to only deal with getting and displaying the information, while the server can focus on storing and manipulating the data. They both have different jobs to do.
REST APIs provide a standardized way of communicating between the client and the data. In other words, it doesn't matter how the server is put together or how the client is coded up — as long as they both structure their communications according to REST architecture guidelines, they can communicate using HTTP! 👌
This is especially useful when you have large teams of developers working on one app. You can have one team work independently on the server-side and another on the client-side because you have the REST API communicating between them. This ability enables developers to scale apps easily and for teams to work more efficiently. 🤝
#2: Stateless
Another unique aspect of REST APIs is that they are stateless - which means that the server does not save any of the previous requests or responses.
But the role of the server is to store and manipulate data. How can it do that if it doesn’t save any requests? 🤔
To return to our metaphor for an API as a waiter, let's say you ask your waiter for french fries. 🍟 Your waiter goes to the kitchen, gets them, and comes back with your order. Success!
But wait! You just remembered you also want ketchup with your fries. So you ask your waiter, "Hey, can I get ketchup with that?" Your waiter would reply: “With what?” A stateless waiter would have no idea what you're talking about because he wouldn't remember that you've just ordered fries! His only job was to transfer orders from customer to kitchen.
So what does that mean for REST APIs? 🤔
Because each message is isolated and independent from the rest, you would need to make sure to send all the necessary data with the request that you make so that you get the most specific response possible. This could go something like - "Hey, can I get ketchup on the fries I ordered at my table?" And then your waiter would be able to identify which fries to add ketchup to!
Statelessness makes each request and response very purposeful and understandable. So, if you're a developer and you see someone else's API request in existing code, you will be able to understand what the request is for without any other context. 👌
#3: Cacheable
The response should contain information about whether or not the client can cache, or save, the data. If it is cacheable, the response should come with a version number. That way, if your user makes the same request twice (i.e., wants to see a page again) and the information hasn’t changed, your server doesn't have to do double the workload to get all the data. Instead, the client can just cache the data the first time and then reload the same data the second time. 💪
An effective cache can reduce the number of times a client and server need to interact, which can help speed up load time for the user! 👏
You may have heard the word cache when referring to something like "Refresh your browser cache." A cache is simply a way to save data so future identical requests can be returned faster. When you visit a bunch of websites on your browser, it can save those requests so it can autocomplete the site you want to go to or load the page faster the next time you visit it. Practical, huh?
#4: Uniform Interface
Developers agree to use the same standards when building a REST API, so every API has a uniform interface. This interface is like a contract between the client and the service that all REST APIs share. It's useful because when developers use APIs, they can be sure to understand each other.
A REST API from one application can communicate in the same way to an entirely different application.
#5: Layered System
Every REST API component does not have access to components beyond the specific one it is interacting with.
Wait… what? What does that mean? 🤔
That means a client that connects to “component A” has no idea if that component is interacting with “component B” or “component Z” afterward. The client just needs to get data back from “component A.” If, for example, you make a request to the Facebook API to retrieve the latest posts, you have no idea what components the Facebook API is communicating with afterward.
This encourages developers to create independent components, making it easier to replace or update each one.
#6: Code on Demand
Code on demand means the server can extend its functionality by sending the code to the client to download. This is optional because not all clients will be able to download and run the same code – so this is not usually used, but at least you know it exists!
Discover the Alternatives to REST APIs
REST is only one type of API. Other alternatives are also good for you to know, notably SOAP APIs.
SOAP stands for Simple Object Access Protocol. Unlike REST, it is considered a protocol, not an architectural style.
SOAP was the most common API before REST came along. While REST uses HTTP to communicate, SOAP can use multiple means of communication. The trouble is, this adds a lot of complexity because developers have to coordinate to ensure they're communicating the same way to avoid problems. Additionally, SOAP can require more bandwidth, which leads to slower page load times. REST was created to resolve some of these issues by being lighter and more flexible.
SOAP is currently used more often in enterprise applications because you can add additional layers of security, data privacy, and integrity. REST can be just as secure, but this needs to be implemented instead of being built-in like it is with SOAP.
Let’s Recap!
Not all APIs are RESTful, but all REST APIs are APIs.
REST APIs have specific architecture guidelines.
Some key advantages to REST APIs are:
Separation between client and server helps apps be more scalable.
Statelessness makes API requests very specific and detail-driven.
Cacheable, which lets clients save data, so they don't have to constantly query servers.
Another popular API type is SOAP.
You’ve just seen how a REST API is structured and its advantages. It’s now time to see what they’re made of: resources. Come with me to the next chapter, where you’ll learn about resources!
