March 18, 2023

Rest API

#101

Table of Contents

  • API
  • REST
  • Why is RESTful API so popular?
  • Basics
  • Idempotent
  • A REST implementation should be stateless.
  • Pagination
  • Versioning

 


I recently stumbled upon the ByteByteGo videos channel and I have to say, I'm thoroughly impressed! Not only do they offer a fantastic newsletter, but their videos and books are top-notch as well.

After spending some time watching their videos, I found that the content was incredibly clear and easy to follow. So, I decided to take some notes to ensure that I could refer back to the information in the future.

API#

Application Programming Interface. It’s a way for two computers to talk to each other. 

REST# 

REST stands for REpresentational State Transfer.

HTTP verbs: CRUD

🚀 POST → CREATE

🚀 GET → READ

🚀 PUT → UPDATE

🚀 DELETE → DELETE

Why is RESTful API so popular?

  • REST is the most common communication standard between computers over the Internet because it’s simple. 
  • RESTful is the common API standard used by most mobile and web applications to talk to the servers is called REST.
  • It is a set of rules that’s the common standard for building web API since the early 2000. 

🚀 An API that follows the REST standard is called a RESTful API.

Examples

Some real life examples are Google Maps. Usually you need an API Key to make a request to google map RESTApi and personalize the response using parameters.

https://www.google.com/maps/embed/v1/place?key=YOUR_API_KEY&q=Eiffel+Tower,Paris+France

Another example could be the Forecast API. You can make requests to the Twitter API directly or use Tweepy, an easy-to-use Python library for accessing the Twitter API.

Basics

RESTful API organizes resources into a set of unique URI or Uniform Resource Identifiers. The URIs differentiate different types of resources on the server. The resources should be grouped by noun and not a verb. 

# An endpoint to get all the products 

https://example.com/api/v3/products
https://example.com/api/v3/users

How this works?

A client interacts with a resource by making a request to the endpoint for that resource over HTTP.

The request has a very specific format like: 

# HTTP VERB + URI

POST /products HTTP/1.1

 

# payload

Accept:application/json

{“customer”: Sofia,

“age”: 29,}

The HTTP verb tells the server what we want to do with the resource. 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. 

  • 200-level → success
  • 400-level → something wrong with our request.
  • 500-level → something wrong at the server level.

🚀 A well-behaved client could choose to retry a failed request with a 500-level status code. You can `could choose to retry` because some actions are not idempotent, and those require extra care.

🚀 The response body is optional and could contain the data payload and is usually formatted in JSON. 

Idempotent

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. 

🚀 POST → Not idempotent

🚀 GET → Idempotent

🚀 PUT → Idempotent

🚀 DELETE → Idempotent

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. 

 

Pagination

If an API endpoint returns a huge amount of data use pagination. A common pagination scheme uses limit and offset as parameters. If they are not specified, the server should assume sensible default values. 

/products?limit=25&offset=50

 

REST API Versioning

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.

/v1/producs
/v2/products

Overall, I highly recommend checking out ByteByteGo if you're looking for quality resources on a variety of topics. From their newsletter to their videos and books, they offer a wealth of knowledge that is well worth exploring.