system design --- RESTAPI

Representational State Transfer —- REST

Architecture

1] previously in one single code base, one single technology — frontend,backend, storage related things are developed —- this is one-tier architecture

• pblm here will happen when it comes to scaling

2] then we have frontend and backend,storage related things as 2 different codebases , and in different technologies for scalability —— this is 2-tier architecture

• this also didnot wrk well for scaling

frontend is client and backend is server

3] then they came up with different architecture where frontend , backend, databases came to picture, here backend and database need not be in same server —-this is 3-tier architecture

• here scaling became easy

• backend also can be divided further into multiple services each served from different servers where each can work on particular features

  • eg: payment, searching etc…

• using RESTAPI the communication b/w these 3 tiers/3 web-services happens

• 

API —- application programming interface —- this interface facilitates 2 application services[frontend,backend,DB] tat are coded in different languages to exchange data/talk to eachother

REST —- it defines rules of how a data must be tranferred b/w 2 web services[client-server,server-server etc…] of different programming languages

• REST provides us some rules and standards to build an API

• API’s follows standards set by REST and delivers the data

HTTP ———- HYPERTEXT TRANSFER PROTOCOL —————— this protocol defines how in the web, data has to be transferred, in which structure ——— REST internally uses HTTP protocol to transfer the data

BENEFITS of RESTAPI [imp qn]

• ease of use

  • eg: on client u can use fetchAPI or anything, on server u can use AXIOS or anything and communication will be easy with RESTAPI

• stateless

  • very powerful feature ——- server wont maintain any info of client, any time client sends a info, it has to send all its details for verification,authentication,prevstate etc…

• scalability

  • more requests? —- increase servers

  • we can increase scalability in realtime also if needed — if we use RESTAPI

• flexibility with data:

  • Allow clients to specify their preferred format using the Accept header in the request. Based on this, the server can respond with data in JSON, XML, or any other supported format.

  •   Accept: application/json
    

  • in java XML is much popular

• UNIFORM INTERFACE:

  • as REST is using HTTP , we are using structure of data already defined in HTTP, so no need to learn totally new structure

• caching:

  • caching in REST APIs can be implemented at different levels, each contributing to improved performance and reduced server load. caching works at the network layer, browser, and server

• seperation of concerns, interoperability:

  • frontend, backend,DB all of them can be in different languages

• Ease of TESTING API

• security:

  • security is essential to protect sensitive data and ensure authorized access. Here are key techniques for securing REST APIs

    • Use HTTPS for Secure Communication

      • Purpose: HTTPS encrypts data in transit, preventing eavesdropping and man-in-the-middle attacks.

      • Best Practice: Redirect all HTTP requests to HTTPS to enforce secure communication

Implement Authentication Headers

• Purpose: Authentication verifies the identity of the user making the request, preventing unauthorized access.

ETC…..

https://dummyjson.com/docs —- here we get dummyAPI’s for a lot of usecases

HTTP request format

• any request tat goes from client to server / server-server has 3 parts

  • HTTP request line

    • it talks abt the method we are using

    • URL we are gonna hit

    • wat is the protocol we are using HTTP/1 ,2 or 3

  • HTTP headers

    • defines lot of behaviour of request

  • HTTP body

HTTP response structure

• 

  HTTP response status line

  protocol used, status code, status msg

• HTTP response headers

  • server rltd info, when response got generated etc…

• HTTP body

  • the data tat we requested for

if we are sending some data along with request —- in devtools network tab, we can see the data we sent in payload subtab

express.js

• it is a framework built on top of node.js

• internally uses JAVASCRIPT

• makes it easy to build a backend or RESTAPI with bare minimum code , increases performance of application also, takes care of security,errorhandling,debugging, helps in creating middlewares, routing etc…

URL

• url decides in a server to which app we have to go, in that app to which part we have to go etc…

• scheme —- tells if our server is http/https

• host —- check above img —- host contains all info inorder to reach right server

• path —- once we reach server using host, in server where we have to go is told by the path

  • this path can be a physical folder structure on server

  • this path can also be a dynamic configuration

• query string —- this is the data tat we are sending along wid request — see it has multiple key pair values seperated by &

• fragment —- this hash wont go from client to server — so make routing carefully based on this —- Fragments are typically handled on the client side. They don’t send any extra information to the server, so they are only useful for controlling page behavior after the page has loaded.

while creating api’s —- its a good practice to create any path starting with ——/api

• 

  

  we can do CRUD operations on an API path

• 

  PUT —- updates whole info of a todo

• PATCH —-updates only a part of info of a TODO

• observe carefully wat method is used for wat operation

• HEAD —- this method is to know info abt wat headers i will be getting in response

• OPTIONS —— this method is for security reasons , here server tells if someone is allowed or not to get the info

• CONNECT —— this method is for using same handshake for multiple requests and responses

• TRACE[used only in devmode] —- this mthd is used for diagnosis if everything is going fine

creating express app

npm init > create npm pkg

• generates package.json

npm i express --save

• generates node_modules, pkglock.json

• adds express as dependency in pkg.json

create index.js file and create ur server

if you want to import express package using import

npm i express --save
import express from 'express';

• go to pkg.json and add type:module under description key — to use about kind of modular import way

our changes are not loading automatically in browser, so for tat live load install nodemon

npm i nodemon --save

after installing in package.json scripts change start script

"start": "nodemon ./index.js"

any data tat is sent from client to server or viceversa is serialised means [stringified]— json.stringify() ;

• once data is reached other end data gets parsed —- json.parse();

in express to parse the data we should install body-parser

npm i body-parser --save

with same path and different methods like post,get etc… we can write different callback fns to be hit in our express backend app

we can use postman to test our backend , even if we dont have a client

• install postman extension is vscode, create a collection and different requests in tat and use it number of times

• from postman — while sending data, select Body —→ raw option —→ select json option and send data

• for GET,DELETE —- no need of any req body

• for put,delete —- we need to send id in URL so tat server can know which record should be updated/deleted

• GET —- to get explicitly only 1 record, we can send id also in URL in get requests

Header

request headers

• 

  

  

  

  any API call we make is listed in this Fetch/XHR tab

• user-agent —- depending on different browsers/OS/processor, our server might have to do different things ,from user agent server can know wat browser,OS etc.. client have

• Accept-language —- preferred response language, and priorities of languages

• Accept-encoding — wat encoding-algorithms tat browser is supporting

  • gzip,deflate,br

  • br is not supported by all broswers, but this is best compression

• connection : makes sure 1 handshake is used for all the requests, no need to establish a new one

• Authorization —- clients sends some token to server so tat server can validate if user is valid or not

• cookie —- Websites use cookies to remember information about you, making your browsing experience smoother and more personalized.

  • Cookies can save your preferences, like language settings or theme choices, so that the site looks or functions the way you like.

  • Cookies track your browsing behavior, allowing sites to show you ads relevant to your interests.

  • it is a key=value combination — comma seperated values

• if-modified-since —- says server tat plz send me new data only if it is modified after the given time — else i will use old one

• cache-control —- It helps control when and for how long web content (like images, stylesheets, and pages) should be stored in the cache, so it doesn't need to be downloaded again on each visit, improving load speed and reducing server load.

response headers

date: tells the exact date on which a response was generated on server

server: tells wat server is sending us the msg —- this leads to security issues— if someone knows wat server we use, they can know wat loopholes such servers have and attack on our server

• we have to explicitly remove this header

content-type —- tells type of response we are getting from server

content-length —- this tells how much data will be loaded onto browser, so tat browser can show loading msg until the whole data[which is of content-length] is downloaded

set-cookie /set-token—- this cookie needs to be stored by client for future use — when we longin we get this header

content-encoding — server tells wat kind of encoding it had done

cache-control —- how long are we gonna cache the data

last-modified —- we can know when the data has been modified last

etag —- vimp — It acts as a unique identifier for a specific version of a resource (like an image, HTML file, or JSON data) on the server.

• With ETags, you can make conditional requests, so the server only sends data when it's different from what’s already cached

expires — server tells client the date/time until which the data is gonna be valid data

status code:

100 —- continue wat ur doing iam processing data

101 — eg: switching connection type,eg: websocket to http

202 —- sever accepted our request and processing it, response will come after a while

204 —- when we delete something we wont get any data back, in such case this is used

206 —- when big data is coming from server, each chunk will have this status,it says still more data will come

3xx —- our application was moved to different server, changed domain name and requests made to old domain must be redirected to new one

• 307,308 —- retains the method[get,put etc… ] also with which they hit the old server and then redirects to new server

400 —- eg: if you send request, whose params were missed say in login info , firstname is missed

401 —- ur not logged in / had access

403 —- ur a user but didnot have access to certain features of app

405 —- the method[get,put etc..] with which ur raising the request is not allowed

429 —- concurrent request 2 people changing same data in a DB at a time

500 —- something wrong with server, it was unable to process the request

502 —- issue with gateway/proxy

503 —- server down

504 —- processing request took more time than it has to

507 —- i have insufficient storage eg: huge data uploads

for some status codes we can automatically retry request eg: for 429

must remember all these requests and methods so that we can correctly use them at r8 places