YT YouTube2Text

YouTube2Text → Transcripts → Everything you need to know about REST

Everything you need to know about REST — Transcript

by Arpit Bhayani · 4,039 words · 574 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00So rest stands for representational
0:02state transfer and here the key idea
0:05around this specification is
0:07representation of entities. So in a
0:10standard client server architecture that
0:12we have your client sends a request and
0:15your server sends a response. The
0:18response that server sends is in some
0:20representation. More often than not we
0:22have seen JSON as the representation.
0:24Here your client is demanding something
0:27from the server and your server is
0:29basically serving the response. Right?
0:32So here what you have on rest is
0:36everything is a resource. Resource
0:39implying that an entity in your system.
0:42For example, if you are building your
0:44library management system, then student
0:47is a resource or book is a resource. If
0:51you're building your e-commerce, then
0:52your seller is a resource. your uh your
0:55user is a resource, your item is a
0:58resource or your purchase order is also
1:01a resource. So the idea here is that in
1:05rest everything is a resource. It can
1:08have its own set of storage. We are not
1:10worrying about that. That is
1:12independent. Rest is actually just a
1:16specification on how your client should
1:20be asking things from your server and
1:22how your server and how your server
1:24should response. That's it. That's all
1:27about rest. So rest being just a
1:30specification, it does not enforces us
1:33to do anything.
1:35It simply suggests that hey you should
1:38be doing these things, right? So that's
1:41where resource becomes the key entity uh
1:45in while while we are adopting rest
1:47right. So any and every data that we
1:50have in our service in our system is an
1:54exposed resource. For example, students
1:57in my library management system is a
2:00resource which I'm exposing through HTTP
2:03endpoints. Right? So the way we the way
2:05we traditionally do but the way student
2:07is stored in my DB is up to me like rest
2:12cannot enforce how I would want to store
2:15that information in my database. Rest
2:18just tells that when I'm talking to my
2:20API server this is the format that I
2:22expected but it does not enforce that
2:25hey you have to store it in tables rows
2:27or you have to store it in MongoDB or
2:29you have to store it in document storage
2:30or key value store. No, not like that.
2:33REST is only there to tell us how your
2:36client and server should communicate or
2:39the way it should communicate.
2:40Everything else is part of our
2:43implementation.
2:45So say we put all the students
2:47information in one table in our
2:48relational storage. All messages in our
2:51chat application maybe goes into Apache
2:53Cassandra. We don't care about that. The
2:55idea is that the way your data is stored
2:58in your database is independent from how
3:01your data is served to your user. So you
3:04may choose to store your student
3:05information in tables, rows, and columns
3:08and serve it as a JSON response.
3:11Perfectly fine. You don't need to have
3:13synergy between the two. You don't need
3:15to have the exactness between the two.
3:18The idea is simple. Store it however you
3:20want but serve it the way client is
3:23asking your data for or the
3:25representation in which client is asking
3:26your data to be served. Right? So this
3:29is where what rest gives you the
3:31flexibility that your client can ask for
3:35a particular representation where your
3:38client says hey give me this data in CSV
3:42format or give me this data in JSON
3:44format or give me this data in XML
3:46format. Your client has an option to ask
3:51uh to ask from the server a particular
3:54data in a particular representation
3:56which is why it is called as
3:58representational state transfer. So you
4:01and obviously it is not mandated as such
4:04but your server should be able to
4:06support that sort of representation but
4:07at least there is a way to do it which
4:09is why you see the HTTP request we make
4:12has a content type header that hey I
4:15sending you content in this type and I'm
4:17expecting a content in this type which
4:19is why HTTP is very widely adopted to
4:21implement rest.
4:23So here a a very solid rest
4:26representation would have multiple
4:29representation of your entities maybe
4:31XML format, JSON format but it is not
4:33mandated that you have to have all of
4:34them. You can choose to just have JSON
4:38as your representation format which is
4:39perfectly fine.
4:42Okay. So let's move to the next part
4:44where what is all about this
4:46representation that we are talking. So
4:48here your client demands a particular
4:51representation of the entity maybe JSON,
4:53text, XML, CSV and your server has to
4:57send the response in that particular
4:59format so long as it is supporting it.
5:01Internal representation can be
5:02different. Your client would make an we
5:06know that most common implementation of
5:07rest is over HTTP. So I'm just basically
5:09carrying forward on that. Uh your client
5:12makes an HTTP request let's say /c
5:15customer/123.
5:17It gets to the server. Server goes to
5:18the database which is your relational
5:20database. Gets it from rows and columns
5:22and creates this entire JSON object and
5:24sends the information in JSON to the
5:26client. So you have two different
5:29representation. One is internal
5:30representation of your entity which is
5:32in table rows and columns and one is
5:34external representation of your entity
5:36which is in JSON. So it it it purely
5:40depends on your server's implementation
5:41on how it wants to send the data or what
5:44all representation would it support.
5:45Right? So here the idea is that any and
5:50every operation that comes or any and
5:52every request that comes from the client
5:54that request has to happen over a
5:58resource and this resource is typically
6:00specified in the HTTP URL that we send.
6:04So here you like when you want to create
6:07a resource, update a resource or delete
6:10a resource, any sort of thing that you
6:11want to do, you can specify it as a
6:14verb. Hey, that this is the action that
6:17I want to take and this is the resource
6:18on which I want to take this action just
6:21a specification. So rest is again just a
6:25specification. So it does not enforce
6:27that hey you have to use this protocol.
6:29So rest is saying that hey you can
6:32choose to use TCP you can choose to use
6:34HTTP you can choose any protocol you
6:37like that to implement rest is just a
6:40specification. So the most common
6:43implementation of rest is with HTTP and
6:46it gels so beautifully well that
6:50by default when we now write APIs we
6:53write rest APIs right the way we define
6:55our URLs is how rest recommends us to do
6:58that and both have become very
7:01synonymous.
7:03the way uh the way we expose endpoints
7:06the way we think we are writing rest we
7:08may not even be writing rest we may just
7:10exposing HTTP endpoints but we always
7:13think that we are writing rest endpoints
7:15right so it's that synonymous so why did
7:18rest and http gel so well what what
7:21happened what happened here so here one
7:25thing that made http uh really solid for
7:30us to adopt rest is http verbs Verbs as
7:33in get, put, post, delete, HTTP methods
7:35that we have. That is a very powerful
7:39feature because with HTTP what you have
7:43is you have this verb or you have this
7:45HTTP method get put post delete and you
7:48have a path or you have a URL on which
7:50you are making that request right. So
7:52this URL is nothing but your resource
7:56and your HTTP verb is the action. So for
8:00example, if I want to delete a
8:02particular user, we expose an endpoint
8:06slash users/ user ID and we expose the
8:09method delete on that. So because delete
8:11is the HTTP verb or HTTP method that is
8:14out of the box supported by all web
8:16servers out there, you can directly
8:18invoke an HTTP delete on / user/1 which
8:24is which becomes your resource
8:25identification. So what does this URL
8:28imply? This URL implies that for a type
8:31res for a type user
8:34which is identified by ID 1 delete it
8:38delete the particular resource. So this
8:42fits so beautifully well that your
8:45action is specified by HTTP method and
8:49your resource is identified by your URL
8:52and which is why we when we expose uh
8:56HTTP endpoint we think we are doing rest
8:58slight difference but you basically get
9:00the gist. So this has to be the
9:02identification of the resource. The the
9:04URL that you have has to be the
9:05identification of the resource while
9:07your delete, get, put, post, all of
9:10these are actions that you want to take
9:11on top of it. The best part over here is
9:15with HTTP verbs, we can multiplex it on
9:18the same resource. So for example I my
9:22URL is / students one which means for a
9:27for a entity type student anyone who is
9:30identified by ID 1 my URL would become /
9:34student/1
9:35and here if I would want to get the
9:37student detail I would do a get on this
9:39URL if I want to update a student detail
9:42I would do a post on this URL if I want
9:44to delete this student I would do a
9:46delete on this URL. So get, put, post,
9:48delete, standard four operations that we
9:50we typically go for. So here what we are
9:53so beautifully doing is we are so
9:56beautifully using the same URL just
9:58changing the method and the entire
10:00connotation is changed and this is a
10:03very well definfined uh specification as
10:06part of HTTP specification that hey
10:08these four methods would be there get
10:10post delete or obviously options patch
10:12and others are exist but you basically
10:15get this idea that HTTP because it is so
10:18widely adopted it has already support
10:20for HTTP methods
10:22which every single client and web server
10:25understands why not piggyback rest on
10:27top of it which is why we still you and
10:31uh we still expose just normal HTTP
10:33endpoint but we chose to do it in a
10:36certain way like /work
10:38no one's enforcing us to do it that way
10:40that is the rest way of doing it you
10:43could have also done something like this
10:45let's say I want to get details of a
10:47particular student I could have done I
10:49could have exposed an endpoint slash get
10:51student in which I am passing in body
10:54the student id and I'm getting this
10:56information out that is also an http
10:58endpoint but that is not rest
11:00implementation that is the difference so
11:03rest says use http methods wisely the
11:07URL should be an identification of your
11:10resource and not the action that you are
11:12taking so for example if I want to
11:14update the student I can say post I can
11:18expose a post method on / student/ / id
11:21and that would update the details of
11:22that particular student or otherwise I
11:24can expose /update student as a method
11:27or as an endpoint and I can take all the
11:29required parameter in the post body and
11:30do that action. So this is where
11:33basically this is exactly where the
11:34difference lies. Rest is how we are now
11:38accustomed to build endpoints /
11:41student/1 is the resource and get put
11:44post delete is the action. Right? So
11:47that's the key difference between HTTP
11:49and rest. So how we are using HTTP to
11:52implement rest. REST is a specification
11:55on how you should be talking to your
11:57server. the way you should be specifying
11:59the input and the output.
12:02Now let's talk about why HTTP gels like
12:06again one very solid reason why HTTP
12:08gels so well with rest because of
12:11toolings. So because web is very widely
12:14adopted obviously the internet is widely
12:15adopted and because of the already
12:18established tooling that we have for
12:21HTTP like for example you have clients
12:25like curl postman request in Python and
12:28whatnot you have clients to make HTTP
12:30request get HTTP response understand the
12:33headers part of it uh set the response
12:35headers and whatnot you have those
12:38toolings in place which means that you
12:41don't have to reinventably you don't
12:43have to build something very different
12:45for this sort of representation or this
12:47sort of specification.
12:49So that's where existing tooling is so
12:50good. Let's say with respect to clients
12:52that you can just import HTTP uh you can
12:55just import uh the request module in
12:57Python and start making HTTP request.
13:00You have the browser you can directly
13:01make post request through form
13:02submission and you have your uh and you
13:05have your rest specification implemented
13:07on your API server. Second web caches
13:10like engineext cache, varnish, haroxy,
13:13so many are there on which you can cache
13:15the responses out which means you can
13:18get good sort of performance without
13:21changing a lot of things because
13:23engineext and all you would anyway have
13:25with rest you are just leveraging what
13:28you already have. You don't have to
13:30build a separate caching mechanism to
13:31solve that problem. Engine X proxy so
13:34many things would do so well. Third,
13:36monitoring tools like distributed
13:38request tracing, uh packet sniffing,
13:41debugging, uh HTTP request response
13:44monitoring, alerting, uh then basically
13:47application performance monitoring,
13:48everything is very well built for HTTP
13:51as a specification. So why would you
13:54want to define your other specification
13:56and rebuild those things? You have your
13:58existing monitoring tools that would
14:00serve just well and get it adopted.
14:03That's why rest over HTTP uh it gels so
14:07well. Next, load balancers. You want to
14:09distribute load uniformly. HTTP based
14:12load balancers are there. They are
14:14ruling the world right now. And you have
14:18all of those things. Why would you want
14:19to have a separate load balancing
14:21strategy for your own specification?
14:24You don't need that. which is why it
14:26gels so so so beautifully well that you
14:28are using your existing ecosystem of
14:32tools and libraries and frameworks and
14:34infra components and whatnot and just
14:37gaining the benefit out of it and
14:39security control SSL uh optimization
14:42technique like compressions and all out
14:44of the box HTTP gives you those
14:46abilities or your web server gives you
14:47those abilities so you don't really have
14:49to worry a lot you can just piggy back
14:51upon existing tools right but obviously
14:54it So well but there are few downsides.
14:57These are just downsides of using rest
15:00over HTTP. This does not mean that we
15:02should not be using it. Obviously the
15:04world uses it. We use it but this does
15:06not mean that we should not be it's just
15:08that we have to be aware of what would
15:11be the potential downsides of using rest
15:13over HTTP just so that we don't make uh
15:16a mistake that would prove very costly
15:19in the future. First of all consumption
15:21is not easy. So here in in one of the
15:26previous videos we talked about RPCs
15:28right uh remote procedure calls there we
15:31saw how stubs are generated and that
15:34stubs makes things native to the
15:36programming language we are using
15:39rest on the other hand because it runs
15:42on top of HTTP there is no
15:43standardization standardization with
15:45respect to the stuff generation or
15:48native objects every single client of
15:51yours And obviously you can use HTTP
15:53client to make a call but when you get
15:55the response you are getting response
15:57say in JSON you have to convert it to a
15:59native object and then consume. So that
16:01is that additional thing that you have
16:03to take care of because it's rest runs
16:06on top of HTTP. There is no native
16:09language involved whatsoever. It's just
16:11a way for you to send a request and get
16:14a response in some format. Here we got
16:17it in JSON response but then you have to
16:20write those things on your own that I
16:22want to I got a JSON response I'm
16:24converting it into let's say you're
16:25writing in Python you get the JSON
16:27response you have to convert it into
16:28dictionary before you consume it let
16:30alone the corresponding classes that you
16:32are expecting right so consumption is
16:35not easy you have to uh do that extra
16:38cialization dialization conversion into
16:40native objects and whatnot that might
16:43become expensive for low latency
16:44application
16:46Second, consumption is repetitive.
16:48Obviously, it's not easy, but it is
16:50repetitive as well. Which means anyone
16:52and everyone who wants to consume the
16:54same uh resource or do that operation on
16:57the same resource, you have to write
16:58that same stuff again and again. For
17:00example, serialization, decentralization
17:02logics to and from native objects,
17:05failures, timeouts, retries,
17:06compression, security and whatnot.
17:09Everyone who is invoking the same
17:12resource or who is trying to do that
17:14same operation on that same resource
17:17let's say through multiple services they
17:18would all have to do it again and again.
17:21A company might have an internal
17:24standardization let's say a common way
17:26to do it but in most cases you would
17:29have to do that thing again and again
17:31right you would have to repeat or create
17:32a shared internal library so that you
17:34know not everyone has to write that same
17:36failures and retries and whatn not
17:39something that gpc or not really gpc but
17:42something that RPC abstracts it out for
17:44you here you would have to build that
17:47shared internal library and everyone has
17:49to do it and then they would be able to
17:51standardize the way the communication
17:53happens by masking or abstracting
17:55failures, retries and whatnot.
17:57The next is some web servers may not
18:00support all HTTP WS. So for a standard
18:03server like let's say Jersey or EngineX
18:05or your uh UWSGI servers, they support
18:09all HTTP WS. But let's say you made a
18:11decision choice of picking a particular
18:13HTTP server that only supports get and
18:17post, does not support put, delete,
18:18patch options. You are stuck with that.
18:21You are stuck with that which means that
18:23you are limiting your potential of using
18:25rest because by changing the HTTP method
18:28you are multiplexing actions on the same
18:31resource. Here you would not be able to
18:33do it. Here you would have just get and
18:36post on that. But if you'd want to
18:37delete you may want to expose some other
18:39kind of endpoint. So slash to run /1 /
18:42delete something like that which is not
18:45really restlike. Right? So the kind of
18:49web server you pick or the kind of text
18:50stack you go for you have to ensure that
18:52it supports all the HTTP verbs out
18:54there. But if your uh any of your
18:58component is not supporting verbs or all
19:00the HTTP verbs it will cause a problem.
19:03You then you are not really doing the
19:06rest way. Right? The next is HTTP
19:09payloads are huge. Example JSON. JSON is
19:13not the format built for low latency
19:16requirement. It is built for
19:18readability. It is not meant for low
19:20latency requirements. So that is where
19:23the HTTP payloads in the request and in
19:26the response that we get in most cases
19:28it would be JSON. So it takes time for
19:32your clients or for your server to
19:34understand the JSON create it or
19:36basically uh parse it into native object
19:38and then consume it. Plus the amount of
19:41data that is transferred with rest is
19:43very repetitive. You have the double
19:45quotes, the string, the the colon and
19:48then the value and then a comma. So many
19:51things are there which looks very
19:53redundant. So that is where the JSON
19:56payloads are very huge uh and not really
19:59suitable for low latency requirements.
20:01So that's where when you have ultra low
20:04when you have low latency requirements,
20:06you typically go for something like RPCs
20:08that use protobuff to to compress your
20:11message in a very very very short uh uh
20:15in a very short payload and then send it
20:17right but obviously it has its own uh
20:19disadvantages but you basically get the
20:21gist for have smaller uh unit of data
20:24transfer you would want to go or for
20:26ultra low latency requirement you might
20:28not want to go for uh rest over HTTP. TP
20:32plus with HTTP what you also get is
20:34every time you make a request you have
20:36to make a three-way handshake TCP
20:37connection then fire the request then
20:38get a response although you can use
20:40HTTP2 but again you have to be wary of
20:42the fact that which HTTP version are you
20:44using to communicate over rest the final
20:47downside that I want to talk about is
20:49switching protocols let's say for some
20:51use case you don't want to use TCP you
20:53want to use UDP changing or switching
20:56protocols with HTTP obviously it's not
20:58possible because HTTP runs on top of TCP
21:01But let's say for some requirement you
21:03wanted to switch to UDP for better
21:05performance and it was okay for you to
21:07lose out on some packets but you wanted
21:09performance out of your system. So then
21:11you would have to go for UDP but if you
21:13went for UDP uh rest over HTTP won't
21:16understand because HTTP only works on
21:18TCP. So which is where you might not be
21:22able to extract the best performance out
21:24of your system given your workload right
21:27it might not be like you always want UDP
21:29but for use case where you would want to
21:31switch protocol it does not give you
21:33that flexibility RPCs give you that
21:36flexibility so but obviously rest is
21:38widely adopted in most cases you would
21:40need it unless you are writing a very
21:41ultra low latency application but still
21:44having that flexibility of changing the
21:45underlying protocol is a pretty solid
21:48advantage that you'll
21:50Right. So using but obviously going
21:52through this downside does not really
21:54mean that we should not be using rest
21:55over HTTP. The entire internet is
21:56working on that and it is pretty pretty
21:59pretty solid very well tested all sorts
22:02of existing toolings works just fine
22:04with that. So unless you have a very
22:07specific requirement don't don't
22:09overthink too much. This was just uh my
22:13way of telling you hey grass is not
22:15always green. uh there are some
22:17limitations and you have to be aware of
22:19it whenever you are adopting something.
22:21So if you have very strict requirement
22:23around uh or not strict but other very
22:26specific requirement pick the right
22:28specification you go for RPC you go for
22:30rest it's up to you but it depends a lot
22:34on the SLS that you would want to
22:36guarantee or the kind of use case that
22:37you have at hand right so just be wary
22:40of the fact this was my way of listing
22:41down all the downsides that you have to
22:43be aware of while using uh rest over
22:46HTTP and yeah that's it that's it for
22:49this one I Hope you now you get an
22:52understanding of what REST is and what
22:54HTTP is and what and just a small
22:56glimpse of about RPCs. If you want if
22:58you are inclined into understanding more
23:00about RPCs, I already have a video on my
23:03channel. You can I would highly
23:04encourage you to check it out if you
23:06have any confusion around RPC that video
23:08would solve the problem for you or it
23:09would help you understand on what RPC is
23:12all about. But today we only talked
23:14about rest and uh how it is different
23:16from HTTP uh upsides of using it, how it
23:20gels so well with HTTP and the downsides
23:23of REST over HTTP so that we are all
23:25aware of uh what we have at hand. So
23:29yeah, that's it. That's it for this
23:31video. Again, if you guys like this
23:32video, give this video a thumbs up. If
23:34you guys like the channel, give this
23:36channel a sub. I post three in-depth
23:37engineering videos every week. And I'll
23:39see you in the next one. Thanks.

About this transcript

This page contains the full transcript of Everything you need to know about REST by Arpit Bhayani, generated from the public captions YouTube serves with the video. The transcript has 4,039 words across 574 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.