--- title: 'What Is REST API? Examples And How To Use It: Crash Course System Design #3' source: 'https://youtube.com/watch?v=-mN3VyJuCjM' video_id: '-mN3VyJuCjM' date: 2026-06-16 duration_sec: 0 --- # What Is REST API? Examples And How To Use It: Crash Course System Design #3 > Source: [What Is REST API? Examples And How To Use It: Crash Course System Design #3](https://youtube.com/watch?v=-mN3VyJuCjM) ## Summary REST is the most common communication standard between computers over the internet. This video explains what an API is, defines REST (REpresentational State Transfer), and covers key principles like statelessness, resource URIs, HTTP verbs, status codes, pagination, and versioning. It concludes by noting REST’s simplicity and comparing it briefly to GraphQL and gRPC. ### Key Points - **REST as the common standard** [0:07] — REST is the most popular API standard used by mobile and web applications to talk to servers. - **Definition of API and REST** [0:21] — API is a way for two computers to talk; REST stands for REpresentational State Transfer and is a set of rules for building web APIs. - **RESTful API examples** [0:48] — Examples include Twilio, Stripe, and Google Maps. - **Resource URIs and nouns** [1:04] — Resources are organized by URIs and should be grouped by noun, not verb (e.g., /products not /getAllProducts). - **HTTP verbs** [1:49] — POST creates, GET reads, PUT updates, DELETE removes (CRUD). - **Request and response structure** [2:10] — Requests may contain an optional JSON body; responses include an HTTP status code and optional data payload. - **HTTP status code levels** [2:38] — 2xx success, 4xx client error (e.g., bad syntax), 5xx server error (e.g., service unavailable). - **Idempotency and retrying** [3:05] — Idempotent APIs (GET, PUT, DELETE) allow safe retries; POST is typically not idempotent. - **Statelessness** [3:38] — REST should be stateless—each request/response is independent, making scaling easier. - **Pagination and versioning** [4:05] — Use pagination (limit/offset) for large datasets; version APIs (e.g., /v1/products) for backward compatibility. ### Conclusion REST remains widely used because it is simple, effective, and good enough for most applications. Other options like GraphQL and gRPC exist and will be compared in future videos. ## Transcript REST is the most common communication standard  between computers over Internet. What is it? Why   is it so popular? Let's take a look. API stands  for Application Programming Interface. It is   a way for two computers to talk to each other.  The common API standard used by most mobile and   web applications to talk to the servers is called  REST. It stands for REpresentational State Transfer.  It is a mouthful. What does that mean? REST is not  a specification. It is a new set of rules that   has been the common standard for building web API  since the early 2000s. An API that follows the REST   standard is called a RESTful API. Some real-life  examples are Twilio, Stripe and Google Maps.   Let's look at the basics of REST. A RESTful API  organizes resources into a set of unique URIs, or   Uniform Resource Identifiers. The URIs  differentiate different types of resources   on a server. Here are some examples. The resources  should be grouped by noun and not verb. An API to   get all products should be slash products and not  slash getAllProducts. A client interacts with a   resource by making a request to the endpoint for  the resource over HTTP. The request has a very   specific format, as shown here. The line contains  the URI for the resource we'd like to access.   The URI is preceded by an HTTP verb which tells  the server what we want to do with the resource.   A POST request means we want to create a  new resource. A GET means we want to read   the data about an existing resource. A PUT is  for updating an existing resource. A DELETE is   for removing an existing resource. You might have  heard the acronym CRUD. This is what it stands for.   In the body of these requests, there could be  an optional HTTP request body that contains   a custom payload of data, usually encoded in  JSON. The server receives a request, processes it,   and formats the result into a response. The first  line of the response contains the HTTP status code   to tell the client what happened to the request.  A well-implemented RESTful API returns proper   HTTP status codes. The 200-level codes mean the  request was successful. The 400-level codes means   something was wrong with our request. For example  the requests contain incorrect syntax. At the 500-  level, it means something went wrong at the server  level. For example, the service was unavailable.   A well-behaved client could choose to retry a  failed request with a 500-level status code. We   said "could choose to retry" because some actions  are not idempotent, and those require extra care   when retrying. When an API is idempotent, making  multiple identical requests has the same effect   as making a single request. This is usually not the  case for a POST request to create a new resource.   The response body is optional and could contain  the data payload and is usually formatted in JSON.   There's a critical attribute of  REST that is worth discussing more.   A REST implementation should be stateless. It  means the two parties don't need to store any   information about each other, and every request  and response (cycle) is independent from all others.   This leads to web applications that are easy to  scale and well behaved. There are two final points   to discuss to round out a well-behaved RESTful API.  If an API endpoint returns a huge amount of data,   use pagination. A common pagination scheme  uses "limit" and "offset" as parameters. Here is   an example. If they are not specified, the server  should assume sensible default values. Lastly,   versioning of an API is very important. Versioning  allows an implementation to provide backward   compatibility, so that if we introduce breaking  changes from one version to another, consumers   can get enough time to move to the next version.  There are many ways to version an API. The most   straightforward is to prefix the version before  the resource on the URI. For instance, like this. RESTful API is simple and effective when  applied sensibly. It may not be the best   choice for all companies, but it is simple and  good enough, and that's why it is so widely used.   There are other popular API options like GraphQL  and gRPC. We'll discuss those and compare them in   separate videos. If you would like to learn more about system  design, check out our books and weekly newsletter.   Please subscribe if you learned something new.  Thank you so much, and we'll see you next time.