1
00:00:00,240 --> 00:00:02,935
-: Okay, so we have discussed the most popular

2
00:00:02,935 --> 00:00:07,935
and common status codes in the three groups of status codes

3
00:00:08,250 --> 00:00:11,700
but actually there are many non-standard codes

4
00:00:11,700 --> 00:00:16,410
which are not part of the W3C standard of the HTTP protocol.

5
00:00:16,410 --> 00:00:19,980
These non-standard codes introduced by various companies

6
00:00:19,980 --> 00:00:23,790
and organizations and are usually used for a very

7
00:00:23,790 --> 00:00:27,570
specific goals that are relevant for these companies.

8
00:00:27,570 --> 00:00:30,741
Such companies include Twitter, Apache, Shopify

9
00:00:30,741 --> 00:00:32,490
and lots more.

10
00:00:32,490 --> 00:00:36,360
Each one of them presented new status codes that are used

11
00:00:36,360 --> 00:00:38,550
by the respective API.

12
00:00:38,550 --> 00:00:43,260
Now, one of the most well-known, non-standard codes are part

13
00:00:43,260 --> 00:00:47,640
of the WebDAV protocol that included some status codes

14
00:00:47,640 --> 00:00:49,560
for document editing.

15
00:00:49,560 --> 00:00:53,130
WebDAV adds many status codes, and as mentioned

16
00:00:53,130 --> 00:00:56,520
almost all of them relevant for document editing.

17
00:00:56,520 --> 00:00:58,920
So let's take a look at one of those

18
00:00:58,920 --> 00:01:00,797
status code introduced by WebDAV.

19
00:01:00,797 --> 00:01:05,459
And this is the 207 - Multi Status.

20
00:01:05,459 --> 00:01:09,300
So when exactly are we going to use this status code?

21
00:01:09,300 --> 00:01:13,380
This is used for cases where multiple entities are handled

22
00:01:13,380 --> 00:01:16,050
each has its own status.

23
00:01:16,050 --> 00:01:19,680
For example, when sending a list of 10 entities

24
00:01:19,680 --> 00:01:21,420
and saving them in the database

25
00:01:21,420 --> 00:01:25,470
then some might fail, and some might succeed.

26
00:01:25,470 --> 00:01:29,160
And we needed to tell the client which entities were failed

27
00:01:29,160 --> 00:01:30,810
and which succeeded.

28
00:01:30,810 --> 00:01:33,630
So with the regular status, we can't do it

29
00:01:33,630 --> 00:01:36,660
because the status returned is a single number

30
00:01:36,660 --> 00:01:40,740
a single status, and we cannot separate the status

31
00:01:40,740 --> 00:01:42,180
for different entities.

32
00:01:42,180 --> 00:01:45,600
But with 207, we can do it.

33
00:01:45,600 --> 00:01:48,600
For example take a look at this example

34
00:01:48,600 --> 00:01:51,120
of the 207 Multi Status.

35
00:01:51,120 --> 00:01:54,180
And as you can see this snippet contains

36
00:01:54,180 --> 00:01:57,300
two responses for two entities.

37
00:01:57,300 --> 00:01:59,880
In this case, both of them were successful and

38
00:01:59,880 --> 00:02:01,380
their respective status is 200.

39
00:02:01,380 --> 00:02:04,170
Okay, but you can also return

40
00:02:04,170 --> 00:02:06,990
other status code for each entity.

41
00:02:06,990 --> 00:02:11,550
Now remember, when returning the 207 Multi Status code

42
00:02:11,550 --> 00:02:16,260
make sure that the client of the API expects such a status.

43
00:02:16,260 --> 00:02:19,080
Remember that we say that most clients are looking for the

44
00:02:19,080 --> 00:02:23,340
200 status and they consider any other status as an error.

45
00:02:23,340 --> 00:02:25,740
So again, make sure the client knows how to

46
00:02:25,740 --> 00:02:29,763
handle a 207 Multi Status code.