[0:07] REST is the most common communication standard 
between computers over Internet. What is it? Why  
[0:14] is it so popular? Let's take a look. API stands 
for Application Programming Interface. It is  
[0:21] a way for two computers to talk to each other. 
The common API standard used by most mobile and  
[0:27] web applications to talk to the servers is called 
REST. It stands for REpresentational State Transfer. 
[0:34] It is a mouthful. What does that mean? REST is not 
a specification. It is a new set of rules that  
[0:41] has been the common standard for building web API 
since the early 2000s. An API that follows the REST  
[0:48] standard is called a RESTful API. Some real-life 
examples are Twilio, Stripe and Google Maps.  
[0:56] Let's look at the basics of REST. A RESTful API 
organizes resources into a set of unique URIs, or  
[1:04] Uniform Resource Identifiers. The URIs 
differentiate different types of resources  
[1:10] on a server. Here are some examples. The resources 
should be grouped by noun and not verb. An API to  
[1:19] get all products should be slash products and not 
slash getAllProducts. A client interacts with a  
[1:27] resource by making a request to the endpoint for 
the resource over HTTP. The request has a very  
[1:34] specific format, as shown here. The line contains 
the URI for the resource we'd like to access.  
[1:41] The URI is preceded by an HTTP verb which tells 
the server what we want to do with the resource.  
[1:49] A POST request means we want to create a 
new resource. A GET means we want to read  
[1:55] the data about an existing resource. A PUT is 
for updating an existing resource. A DELETE is  
[2:02] for removing an existing resource. You might have 
heard the acronym CRUD. This is what it stands for.  
[2:10] In the body of these requests, there could be 
an optional HTTP request body that contains  
[2:15] a custom payload of data, usually encoded in 
JSON. The server receives a request, processes it,  
[2:23] and formats the result into a response. The first 
line of the response contains the HTTP status code  
[2:31] to tell the client what happened to the request. 
A well-implemented RESTful API returns proper  
[2:38] HTTP status codes. The 200-level codes mean the 
request was successful. The 400-level codes means  
[2:45] something was wrong with our request. For example 
the requests contain incorrect syntax. At the 500- 
[2:52] level, it means something went wrong at the server 
level. For example, the service was unavailable.  
[2:59] A well-behaved client could choose to retry a 
failed request with a 500-level status code. We  
[3:05] said "could choose to retry" because some actions 
are not idempotent, and those require extra care  
[3:12] when retrying. When an API is idempotent, making 
multiple identical requests has the same effect  
[3:19] as making a single request. This is usually not the 
case for a POST request to create a new resource.  
[3:26] The response body is optional and could contain 
the data payload and is usually formatted in JSON.  
[3:34] There's a critical attribute of 
REST that is worth discussing more.  
[3:38] A REST implementation should be stateless. It 
means the two parties don't need to store any  
[3:44] information about each other, and every request 
and response (cycle) is independent from all others.  
[3:50] This leads to web applications that are easy to 
scale and well behaved. There are two final points  
[3:57] to discuss to round out a well-behaved RESTful API. 
If an API endpoint returns a huge amount of data,  
[4:05] use pagination. A common pagination scheme 
uses "limit" and "offset" as parameters. Here is  
[4:12] an example. If they are not specified, the server 
should assume sensible default values. Lastly,  
[4:20] versioning of an API is very important. Versioning 
allows an implementation to provide backward  
[4:27] compatibility, so that if we introduce breaking 
changes from one version to another, consumers  
[4:33] can get enough time to move to the next version. 
There are many ways to version an API. The most  
[4:40] straightforward is to prefix the version before 
the resource on the URI. For instance, like this.
[4:48] RESTful API is simple and effective when 
applied sensibly. It may not be the best  
[4:54] choice for all companies, but it is simple and 
good enough, and that's why it is so widely used.  
[5:00] There are other popular API options like GraphQL 
and gRPC. We'll discuss those and compare them in  
[5:09] separate videos. If you would like to learn more about system 
design, check out our books and weekly newsletter.  
[5:14] Please subscribe if you learned something new. 
Thank you so much, and we'll see you next time.