Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated:
1
00:00:01,670 --> 00:00:04,320
So now that we know what Express is,
2
00:00:04,320 --> 00:00:07,550
we're almost ready to start building our API.
3
00:00:07,550 --> 00:00:08,890
But before we do that,
4
00:00:08,890 --> 00:00:12,300
I need to quickly talk about APIs on a higher level,
5
00:00:12,300 --> 00:00:13,910
and more importantly,
6
00:00:13,910 --> 00:00:16,370
introduce you to the REST Architecture
7
00:00:16,370 --> 00:00:19,640
which is the most used API architecture today.
8
00:00:19,640 --> 00:00:23,270
This way, we will actually know what we're building.
9
00:00:23,270 --> 00:00:25,710
So it's extremely important to understand the stuff
10
00:00:25,710 --> 00:00:27,860
in this video before moving on,
11
00:00:27,860 --> 00:00:30,580
so that we actually know what we're building
12
00:00:30,580 --> 00:00:32,603
throughout the rest of the course.
13
00:00:33,630 --> 00:00:34,890
First of all,
14
00:00:34,890 --> 00:00:38,390
API stands for Application Programming Interface
15
00:00:38,390 --> 00:00:40,130
and on a very high level,
16
00:00:40,130 --> 00:00:43,150
it's basically a piece of software that can be used
17
00:00:43,150 --> 00:00:45,270
by another piece of software
18
00:00:45,270 --> 00:00:48,213
in order to allow applications to talk to each other.
19
00:00:49,080 --> 00:00:51,420
We have actually talked about APIs before,
20
00:00:51,420 --> 00:00:53,780
more specifically, web APIs,
21
00:00:53,780 --> 00:00:56,300
where we simply built an app that sends data
22
00:00:56,300 --> 00:00:59,640
to a client whenever a request comes in.
23
00:00:59,640 --> 00:01:02,530
Imagine we have our app running on a server
24
00:01:02,530 --> 00:01:04,060
and we have a client.
25
00:01:04,060 --> 00:01:08,020
So in fact, we effectively have two pieces of software
26
00:01:08,020 --> 00:01:10,250
talking to each other, right?
27
00:01:10,250 --> 00:01:13,550
And this is the kind of API we will build in this course.
28
00:01:13,550 --> 00:01:17,470
And I guess it's the most widely used type of API out there.
29
00:01:17,470 --> 00:01:21,970
But in fact, APIs aren't only used to send data,
30
00:01:21,970 --> 00:01:25,493
and aren't always related to web development or JavaScript.
31
00:01:26,400 --> 00:01:29,500
The application in API can actually mean
32
00:01:29,500 --> 00:01:32,710
many different things as long as the piece of software
33
00:01:32,710 --> 00:01:35,050
is relatively stand alone.
34
00:01:35,050 --> 00:01:35,900
Take for example,
35
00:01:35,900 --> 00:01:38,870
the Node File System, or the HTTP Modules.
36
00:01:38,870 --> 00:01:42,010
We can say that they are small pieces of software
37
00:01:42,010 --> 00:01:43,110
and we can use them,
38
00:01:43,110 --> 00:01:46,970
we can interact with them by using their API.
39
00:01:46,970 --> 00:01:47,803
For example,
40
00:01:47,803 --> 00:01:51,150
when we use the readfile function from the FS Module,
41
00:01:51,150 --> 00:01:54,020
we are actually using the FS API.
42
00:01:54,020 --> 00:01:57,380
And that's why you will sometimes hear the term node APIs.
43
00:01:57,380 --> 00:02:01,090
And that usually simply refers to the core node modules
44
00:02:01,090 --> 00:02:02,920
that we can interact with.
45
00:02:02,920 --> 00:02:05,670
Or when we do DOM manipulation in the browser,
46
00:02:05,670 --> 00:02:08,650
we are not really using the JavaScript language itself,
47
00:02:08,650 --> 00:02:12,440
but rather, the DOM API that the browser exposes to us,
48
00:02:12,440 --> 00:02:14,280
so it gives us access to it.
49
00:02:14,280 --> 00:02:15,930
Or even another example,
50
00:02:15,930 --> 00:02:19,080
let's say we create a class in any programming language
51
00:02:19,080 --> 00:02:21,940
like Java and then add some public methods
52
00:02:21,940 --> 00:02:23,420
or properties to it.
53
00:02:23,420 --> 00:02:26,860
These methods will then be the API of each object
54
00:02:26,860 --> 00:02:29,450
created from that class because we're giving
55
00:02:29,450 --> 00:02:31,890
other pieces of software the possibility
56
00:02:31,890 --> 00:02:35,420
of interacting with our initial piece of software,
57
00:02:35,420 --> 00:02:37,278
the objects, in this case.
58
00:02:37,278 --> 00:02:40,810
You see, API has actually a broader meaning
59
00:02:40,810 --> 00:02:42,810
than just building web APIs.
60
00:02:42,810 --> 00:02:47,420
Alright? Anyway, a web API is what's most important
61
00:02:47,420 --> 00:02:50,340
for us in the context of note.
62
00:02:50,340 --> 00:02:53,050
Let's now take a look at the REST Architecture
63
00:02:53,050 --> 00:02:54,203
to build APIs.
64
00:02:55,820 --> 00:02:59,910
REST, which stands for Representational States Transfer,
65
00:02:59,910 --> 00:03:03,930
is basically a way of building web APIs in a logical way,
66
00:03:03,930 --> 00:03:06,060
making them easy to consume
67
00:03:06,060 --> 00:03:09,420
because remember, we build an API for ourselves
68
00:03:09,420 --> 00:03:12,023
or for others to consume, okay?
69
00:03:12,023 --> 00:03:15,640
We want to make the process of actually using the API
70
00:03:15,640 --> 00:03:17,633
as smooth as possible for the user.
71
00:03:18,490 --> 00:03:20,830
Now, to build RESTful APIs,
72
00:03:20,830 --> 00:03:24,180
which means APIs following the REST Architecture,
73
00:03:24,180 --> 00:03:26,660
we just need to follow a couple of principles.
74
00:03:26,660 --> 00:03:31,240
First, we need to separate our API into logical resources.
75
00:03:31,240 --> 00:03:33,860
These resources should then be exposed,
76
00:03:33,860 --> 00:03:35,900
which means to be made available
77
00:03:35,900 --> 00:03:39,420
using structured, resource-based URLs.
78
00:03:39,420 --> 00:03:41,460
To perform different actions on data
79
00:03:41,460 --> 00:03:44,677
like reading or creating or deleting data,
80
00:03:44,677 --> 00:03:49,677
the API should use the right HTP methods and not the URL.
81
00:03:50,270 --> 00:03:53,210
Now, the data that we actually send back to the client
82
00:03:53,210 --> 00:03:55,420
or that we received from the client
83
00:03:55,420 --> 00:03:58,030
should usually use the JSON data format,
84
00:03:58,030 --> 00:04:01,010
where some formatting standard applied to it.
85
00:04:01,010 --> 00:04:04,500
Finally, another important principle of REST APIs
86
00:04:04,500 --> 00:04:07,560
is that they must be stateless.
87
00:04:07,560 --> 00:04:09,950
So this is a very broad overview.
88
00:04:09,950 --> 00:04:12,030
Let's now start talking about these principles
89
00:04:12,030 --> 00:04:15,310
one-by-one starting with resources
90
00:04:15,310 --> 00:04:17,810
and using the Nators API that we're gonna build
91
00:04:17,810 --> 00:04:19,803
in this course as an example here.
92
00:04:20,959 --> 00:04:24,910
The key abstraction of information in REST is a resource,
93
00:04:24,910 --> 00:04:27,450
and therefore all the data that we wanna share
94
00:04:27,450 --> 00:04:32,040
in the API should be divided into logical resources.
95
00:04:32,040 --> 00:04:34,350
Now, what actually is a resource?
96
00:04:34,350 --> 00:04:36,380
Well, in the context of REST,
97
00:04:36,380 --> 00:04:39,520
it is an object or a representation of something
98
00:04:39,520 --> 00:04:42,020
which has some data associated to it.
99
00:04:42,020 --> 00:04:42,853
For example,
100
00:04:42,853 --> 00:04:45,570
tours, or users, or reviews in the case
101
00:04:45,570 --> 00:04:48,020
of the example that we are following.
102
00:04:48,020 --> 00:04:50,730
So basically, any information that can be named
103
00:04:50,730 --> 00:04:53,040
can be a resource, alright?
104
00:04:53,040 --> 00:04:56,050
It just has to be a name, though, not a verb.
105
00:04:56,050 --> 00:04:57,690
Now, we need to expose,
106
00:04:57,690 --> 00:04:59,480
which means to make available,
107
00:04:59,480 --> 00:05:02,520
the data using some structured URLs
108
00:05:02,520 --> 00:05:04,890
that the client can send a request to.
109
00:05:04,890 --> 00:05:07,611
For example, something like this.
110
00:05:07,611 --> 00:05:10,740
This entire address is called the URL
111
00:05:10,740 --> 00:05:14,323
and this /addNewTour is called an API Endpoint.
112
00:05:15,269 --> 00:05:17,840
Our API will have many different endpoints
113
00:05:17,840 --> 00:05:20,560
just like this fictional endpoints that I have here,
114
00:05:20,560 --> 00:05:23,730
each of which will send different data back to the client
115
00:05:23,730 --> 00:05:26,150
or also perform different actions.
116
00:05:26,150 --> 00:05:28,440
Now, there's actually something very wrong
117
00:05:28,440 --> 00:05:31,750
with these endpoints here because they really don't follow
118
00:05:31,750 --> 00:05:34,827
the third rule which says that we should only use
119
00:05:34,827 --> 00:05:39,110
the HTTP methods in order to perform actions on data.
120
00:05:39,110 --> 00:05:42,360
So, endpoints should only contain our resources
121
00:05:42,360 --> 00:05:45,070
and not the actions that can be performed on them
122
00:05:45,070 --> 00:05:48,313
because they will quickly become a nightmare to maintain.
123
00:05:49,644 --> 00:05:54,210
How should we use these HTTP methods in practice?
124
00:05:54,210 --> 00:05:56,120
Well, let's see how these endpoints
125
00:05:56,120 --> 00:05:59,620
should actually look like starting with /getTour.
126
00:05:59,620 --> 00:06:03,290
So this /getTour endpoint is to get data about a tour.
127
00:06:03,290 --> 00:06:06,240
And so we should simply name the endpoint /tours
128
00:06:06,240 --> 00:06:08,740
and send the data whenever a get request
129
00:06:08,740 --> 00:06:10,430
is made to this endpoint.
130
00:06:10,430 --> 00:06:11,650
So in other words,
131
00:06:11,650 --> 00:06:14,730
when a client uses a GET HTTP method
132
00:06:14,730 --> 00:06:16,700
to access the endpoint.
133
00:06:16,700 --> 00:06:17,870
And just like this,
134
00:06:17,870 --> 00:06:20,220
we only have resources in the endpoint
135
00:06:20,220 --> 00:06:23,670
or in the URL and no verbs because the verb
136
00:06:23,670 --> 00:06:26,870
is now in the HTTP method, right?
137
00:06:26,870 --> 00:06:27,703
And by the way,
138
00:06:27,703 --> 00:06:30,490
it's a common practice to always use the resource name
139
00:06:30,490 --> 00:06:34,820
in plural which is why I have /tours here and not /tour.
140
00:06:34,820 --> 00:06:37,790
Now, the convention is that when calling that endpoint,
141
00:06:37,790 --> 00:06:41,820
we get back all the tours that are in a database, okay?
142
00:06:41,820 --> 00:06:44,820
But if we only want the tour with one I.D.,
143
00:06:44,820 --> 00:06:48,960
let's say seven, we add that seven after another slash
144
00:06:48,960 --> 00:06:50,580
or in a search query.
145
00:06:50,580 --> 00:06:53,490
Or it could also be the name of a tour instead of the I.D.,
146
00:06:53,490 --> 00:06:55,410
or some other unique identifier.
147
00:06:55,410 --> 00:06:58,300
The detail doesn't really matter at this point, alright?
148
00:06:58,300 --> 00:07:01,180
Later, I will show you how easy it is to actually implement
149
00:07:01,180 --> 00:07:03,410
this kind of logic with Express
150
00:07:03,410 --> 00:07:06,733
because this is actually where Express really shines.
151
00:07:07,606 --> 00:07:10,460
The first HTTP method or verb
152
00:07:10,460 --> 00:07:12,530
that we can respond to is GET
153
00:07:12,530 --> 00:07:16,290
and it's used to perform the Read operation on data.
154
00:07:16,290 --> 00:07:18,290
Next stop, if the client wants
155
00:07:18,290 --> 00:07:21,450
to create a new resource in our database,
156
00:07:21,450 --> 00:07:23,200
in this example, a new tour,
157
00:07:23,200 --> 00:07:25,510
the POST method should be used.
158
00:07:25,510 --> 00:07:28,490
So we learned earlier that a POST request can be used
159
00:07:28,490 --> 00:07:30,230
to send data to the server,
160
00:07:30,230 --> 00:07:32,270
and so it makes sense to use POST
161
00:07:32,270 --> 00:07:35,530
in order to create new resources, right?
162
00:07:35,530 --> 00:07:38,530
Now in this case, usually no I.D. will be sent
163
00:07:38,530 --> 00:07:40,860
because the server should automatically figure out
164
00:07:40,860 --> 00:07:42,948
the I.D. for the new resource.
165
00:07:42,948 --> 00:07:46,090
Anyway, what's really important to note here
166
00:07:46,090 --> 00:07:50,289
is how the endpoint name is the exact same name as before.
167
00:07:50,289 --> 00:07:53,870
The only difference is really the HTP method
168
00:07:53,870 --> 00:07:55,960
that is used for the request.
169
00:07:55,960 --> 00:07:59,410
If the /tours endpoint is accessed with GET,
170
00:07:59,410 --> 00:08:01,460
we send data to the client.
171
00:08:01,460 --> 00:08:04,060
But if the same endpoint is accessed with POST,
172
00:08:04,060 --> 00:08:06,550
we expect data to come in with a request,
173
00:08:06,550 --> 00:08:08,760
so that we can then create a new resource
174
00:08:08,760 --> 00:08:10,330
on the server side.
175
00:08:10,330 --> 00:08:14,460
So that is really the beauty of only using HTTP methods
176
00:08:14,460 --> 00:08:17,480
rather than messing with verbs in endpoint names.
177
00:08:17,480 --> 00:08:21,210
Again, it would really become unmanageable very quick.
178
00:08:21,210 --> 00:08:23,620
Alright, next, there should also be
179
00:08:23,620 --> 00:08:26,390
the ability to update resources.
180
00:08:26,390 --> 00:08:27,310
And for that,
181
00:08:27,310 --> 00:08:29,550
either a PUT or a PATCH request
182
00:08:29,550 --> 00:08:31,550
should be made to the endpoint.
183
00:08:31,550 --> 00:08:33,750
The difference between them is that with PUT,
184
00:08:33,750 --> 00:08:37,280
the client is supposed to send the entire updated object,
185
00:08:37,280 --> 00:08:38,370
while with PATCH,
186
00:08:38,370 --> 00:08:40,967
it is supposed to send only the part of the object
187
00:08:40,967 --> 00:08:43,059
that has been changed.
188
00:08:43,059 --> 00:08:45,140
But both of them have the ability
189
00:08:45,140 --> 00:08:46,750
to send data to the server.
190
00:08:46,750 --> 00:08:50,750
A bit like POST, actually, but with a different intent.
191
00:08:50,750 --> 00:08:53,070
So POST is to create a new resource,
192
00:08:53,070 --> 00:08:55,370
while PUT or PATCH are used
193
00:08:55,370 --> 00:08:57,500
to update an existing resource
194
00:08:57,500 --> 00:08:59,660
and so it then makes all the difference.
195
00:08:59,660 --> 00:09:02,110
And finally, to the litter resource,
196
00:09:02,110 --> 00:09:05,110
there is the DELETE HTTP method.
197
00:09:05,110 --> 00:09:08,010
Again, the I.D. or some other unique identifier
198
00:09:08,010 --> 00:09:10,120
of the resource to be deleted
199
00:09:10,120 --> 00:09:11,820
should be part of the URL.
200
00:09:11,820 --> 00:09:14,560
Now, usually, in order to actually be able
201
00:09:14,560 --> 00:09:16,610
to perform this kind of request,
202
00:09:16,610 --> 00:09:18,620
the client must be authenticated.
203
00:09:18,620 --> 00:09:21,670
So basically, log into your app, okay?
204
00:09:21,670 --> 00:09:24,349
But that is, of course, a topic for much later.
205
00:09:24,349 --> 00:09:27,080
So these are the five HTTP methods
206
00:09:27,080 --> 00:09:29,320
that we can and should respond to
207
00:09:29,320 --> 00:09:31,570
when building our RESTful APIs
208
00:09:31,570 --> 00:09:33,270
so that the client can perform
209
00:09:33,270 --> 00:09:36,290
the four basic CRUD operations.
210
00:09:36,290 --> 00:09:40,730
So CRUD stands for Create, Read, Update and Delete.
211
00:09:40,730 --> 00:09:42,590
And you will see this term all the time
212
00:09:42,590 --> 00:09:45,200
related to APIs and database stuff.
213
00:09:45,200 --> 00:09:47,490
And you see that these HTTP methods
214
00:09:47,490 --> 00:09:51,330
map quite nicely to the basic CRUD operations.
215
00:09:51,330 --> 00:09:54,410
Now, there might be actions that are not CRUD,
216
00:09:54,410 --> 00:09:55,460
and in that case,
217
00:09:55,460 --> 00:09:58,120
we just need to get creative with our inputs.
218
00:09:58,120 --> 00:09:58,953
For example,
219
00:09:58,953 --> 00:10:01,010
a log in or a search operation,
220
00:10:01,010 --> 00:10:04,361
these are not really related to a particular resource
221
00:10:04,361 --> 00:10:06,630
and they're not CRUD operations either,
222
00:10:06,630 --> 00:10:09,240
but we still can create endpoints for them.
223
00:10:09,240 --> 00:10:12,530
For example, like /login or /search.
224
00:10:12,530 --> 00:10:16,350
But we'll talk more about these cases later in practice.
225
00:10:16,350 --> 00:10:18,290
And just to finish this part now,
226
00:10:18,290 --> 00:10:21,330
remember that we had two other crazy endpoint names
227
00:10:21,330 --> 00:10:23,870
in the last slide which kind of involved
228
00:10:23,870 --> 00:10:26,780
two resources at the same time, right?
229
00:10:26,780 --> 00:10:29,888
And that's also no problem at all with REST.
230
00:10:29,888 --> 00:10:33,810
So, /getToursByUser can simply be translated
231
00:10:33,810 --> 00:10:36,210
to /users/tours,
232
00:10:36,210 --> 00:10:38,440
in this case, user number three.
233
00:10:38,440 --> 00:10:40,200
So this particular endpoint here
234
00:10:40,200 --> 00:10:42,340
could send data about all the tours
235
00:10:42,340 --> 00:10:44,580
that user number three has booked.
236
00:10:44,580 --> 00:10:45,519
Makes sense?
237
00:10:45,519 --> 00:10:47,470
Or in the case of deleting,
238
00:10:47,470 --> 00:10:50,170
there could be a delete request to the same
239
00:10:50,170 --> 00:10:51,910
or a very similar endpoint,
240
00:10:51,910 --> 00:10:54,440
requesting tour number nine to be deleted
241
00:10:54,440 --> 00:10:57,330
from user number three, okay?
242
00:10:57,330 --> 00:11:00,160
So there really are a tons of possibilities
243
00:11:00,160 --> 00:11:02,470
of combining resources like this.
244
00:11:02,470 --> 00:11:04,260
But of course, we don't have to implement
245
00:11:04,260 --> 00:11:06,600
all these combinations in our API.
246
00:11:06,600 --> 00:11:08,400
We only implement what makes sense
247
00:11:08,400 --> 00:11:10,090
in the case of our application
248
00:11:10,090 --> 00:11:13,203
and the client that wants to consume our API.
249
00:11:13,203 --> 00:11:17,480
So, this is how we make use of HTTP methods
250
00:11:17,480 --> 00:11:20,823
to build user-friendly and nicely structured URLs
251
00:11:20,823 --> 00:11:24,145
that are easy and logical to consume for the client.
252
00:11:24,145 --> 00:11:27,800
Now, about the data that the client actually receives,
253
00:11:27,800 --> 00:11:30,610
or that the server receives from the client,
254
00:11:30,610 --> 00:11:33,203
usually, we use the JSON Data Format.
255
00:11:34,440 --> 00:11:37,400
And so let's briefly learn what JSON actually is
256
00:11:37,400 --> 00:11:39,530
and how to format our API responses.
257
00:11:39,530 --> 00:11:43,780
JSON is a very lightweight data interchange format
258
00:11:43,780 --> 00:11:46,220
which is heavily used by web APIs
259
00:11:46,220 --> 00:11:48,160
coded in any programming language.
260
00:11:48,160 --> 00:11:50,740
So it's just not related to a JavaScript.
261
00:11:50,740 --> 00:11:52,620
And it's so widely used today
262
00:11:52,620 --> 00:11:55,930
because it's really easy for both humans and computers
263
00:11:55,930 --> 00:11:57,990
to understand and write JSON.
264
00:11:57,990 --> 00:12:00,510
So you're probably already noticing that JSON
265
00:12:00,510 --> 00:12:04,020
looks a bit like a regular JavaScript object, right?
266
00:12:04,020 --> 00:12:06,470
With all these key-value pairs.
267
00:12:06,470 --> 00:12:08,320
There are, however, some differences,
268
00:12:08,320 --> 00:12:10,960
and the most important one is that all the keys
269
00:12:10,960 --> 00:12:12,580
have to be strings.
270
00:12:12,580 --> 00:12:14,730
It's also very typical for the values
271
00:12:14,730 --> 00:12:17,440
to be strings as well but they can be other things
272
00:12:17,440 --> 00:12:20,690
like numbers, true or false values, other object,
273
00:12:20,690 --> 00:12:23,328
or even arrays of other values.
274
00:12:23,328 --> 00:12:25,790
It's quite straighforward, actually.
275
00:12:25,790 --> 00:12:27,070
And from this example,
276
00:12:27,070 --> 00:12:30,883
you can kind of see how some typical JSON might look like.
277
00:12:31,890 --> 00:12:35,290
Let's say that this is a data that we have in our database
278
00:12:35,290 --> 00:12:38,560
for a GET request to this URL
279
00:12:38,560 --> 00:12:41,440
so the tour with I.D. of five.
280
00:12:41,440 --> 00:12:44,300
Now, we could send it back like this to the client,
281
00:12:44,300 --> 00:12:47,130
but we usually do some simple response formatting
282
00:12:47,130 --> 00:12:48,620
before sending.
283
00:12:48,620 --> 00:12:50,880
There are a couple of standards for this
284
00:12:50,880 --> 00:12:54,570
and we're gonna use a very simple one called Jsend.
285
00:12:54,570 --> 00:12:56,320
We simply create a new object,
286
00:12:56,320 --> 00:12:58,310
then add a status message to it
287
00:12:58,310 --> 00:13:00,740
in order to inform the client whether the request
288
00:13:00,740 --> 00:13:03,350
was a success, fail or error,
289
00:13:03,350 --> 00:13:05,390
and then we put our original data
290
00:13:05,390 --> 00:13:08,510
into a new object called Data, okay?
291
00:13:08,510 --> 00:13:10,640
And we can develop this even a bit further
292
00:13:10,640 --> 00:13:12,020
but this is really the simplest way
293
00:13:12,020 --> 00:13:14,250
of formatting with Jsend.
294
00:13:14,250 --> 00:13:15,240
And just, by the way,
295
00:13:15,240 --> 00:13:17,550
wrapping the data into an additional object
296
00:13:17,550 --> 00:13:19,860
like we did here is called Enveloping,
297
00:13:19,860 --> 00:13:21,470
and it's a common practice
298
00:13:21,470 --> 00:13:25,550
to mitigate some security issues and other problems.
299
00:13:25,550 --> 00:13:27,200
Also, there are other standards
300
00:13:27,200 --> 00:13:30,330
for response-formatting that you can look into,
301
00:13:30,330 --> 00:13:34,333
like Jsend:API or the Odata JSON Protocol.
302
00:13:35,800 --> 00:13:37,470
Alright, and finally,
303
00:13:37,470 --> 00:13:40,720
a RESTful API should always be stateless.
304
00:13:40,720 --> 00:13:43,170
So, what does stateless actually mean?
305
00:13:43,170 --> 00:13:45,960
Well, in a stateless RESTful API,
306
00:13:45,960 --> 00:13:48,410
all state is handled on the client
307
00:13:48,410 --> 00:13:50,120
and not on the server.
308
00:13:50,120 --> 00:13:52,910
And state simply refers to a piece of data
309
00:13:52,910 --> 00:13:55,750
in the application that might change over time.
310
00:13:55,750 --> 00:13:56,583
For example,
311
00:13:56,583 --> 00:13:58,720
whether a certain user is logged in
312
00:13:58,720 --> 00:14:02,230
or on a page with a list with several pages,
313
00:14:02,230 --> 00:14:04,150
what the current page is.
314
00:14:04,150 --> 00:14:06,170
Now the fact that the state should be handled
315
00:14:06,170 --> 00:14:09,910
on the client means that each request must contain
316
00:14:09,910 --> 00:14:12,710
all the information that is necessary to process
317
00:14:12,710 --> 00:14:15,780
a certain request on the server, alright?
318
00:14:15,780 --> 00:14:17,170
Does that make sense?
319
00:14:17,170 --> 00:14:21,030
So, the server should never ever have to remember
320
00:14:21,030 --> 00:14:24,010
the previous request in order to process
321
00:14:24,010 --> 00:14:25,906
the current request.
322
00:14:25,906 --> 00:14:29,670
Let's take the list with several pages as an example.
323
00:14:29,670 --> 00:14:32,980
And let's say that recurrently on page five
324
00:14:32,980 --> 00:14:36,006
and want to move forward to page six.
325
00:14:36,006 --> 00:14:39,710
So we could have a simple endpoint called /tours/nextPage
326
00:14:40,650 --> 00:14:43,400
and submit a request to it, right?
327
00:14:43,400 --> 00:14:45,610
But the server would then have to figure out
328
00:14:45,610 --> 00:14:48,450
what the current page is and based on that
329
00:14:48,450 --> 00:14:50,496
send the next page to the client.
330
00:14:50,496 --> 00:14:51,730
In other words,
331
00:14:51,730 --> 00:14:54,950
the server would have to remember the previous request.
332
00:14:54,950 --> 00:14:57,640
It would have to handle the state server side
333
00:14:57,640 --> 00:15:00,260
and that is exactly what we want to avoid
334
00:15:00,260 --> 00:15:03,120
in RESTful APIs, okay?
335
00:15:03,120 --> 00:15:04,630
Instead, in this case,
336
00:15:04,630 --> 00:15:07,550
we should create a /tours/page endpoint
337
00:15:07,550 --> 00:15:09,410
and paste the number six to it
338
00:15:09,410 --> 00:15:11,850
in order to request page number six.
339
00:15:11,850 --> 00:15:14,340
This way, we would then state on the client
340
00:15:14,340 --> 00:15:15,410
because on a client,
341
00:15:15,410 --> 00:15:18,320
we would already know that we're on page five
342
00:15:18,320 --> 00:15:20,750
and so all we had to do is to just add one
343
00:15:20,750 --> 00:15:22,750
and then request page number six.
344
00:15:22,750 --> 00:15:23,920
So the server doesn't have
345
00:15:23,920 --> 00:15:25,840
to remember anything in this case.
346
00:15:25,840 --> 00:15:27,940
All it has to do is to send back data
347
00:15:27,940 --> 00:15:30,840
for page number six as we requested.
348
00:15:30,840 --> 00:15:33,891
And by the way, statelessness and statefulness,
349
00:15:33,891 --> 00:15:35,760
which is the opposite,
350
00:15:35,760 --> 00:15:38,560
are very important concepts in computer science
351
00:15:38,560 --> 00:15:40,800
and application design in general.
352
00:15:40,800 --> 00:15:44,070
So, it's a good idea to actually have some understanding
353
00:15:44,070 --> 00:15:47,331
what a stateless API is and how it works.
354
00:15:47,331 --> 00:15:50,280
Anyway, this was a huge lecture,
355
00:15:50,280 --> 00:15:52,670
but also one of the most important ones.
356
00:15:52,670 --> 00:15:55,700
I cannot stress that enough and I actually think
357
00:15:55,700 --> 00:15:57,800
that you can see that, right?
358
00:15:57,800 --> 00:16:00,803
Anyway, let's now finally get back to our code.
28115
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.