1
00:00:00,920 --> 00:00:03,710
In the last video we successfully edited a stream.

2
00:00:03,770 --> 00:00:05,140
I'd definitely change the description.

3
00:00:05,140 --> 00:00:06,110
This one right here.

4
00:00:06,160 --> 00:00:10,930
But when we came back to the streamlets page I no longer see the buttons to edit and delete the stream.

5
00:00:11,080 --> 00:00:15,140
So that seems a little bit off but I bet we can figure out what's going on here.

6
00:00:15,160 --> 00:00:17,670
I'm going to open up my network request tab right here.

7
00:00:17,710 --> 00:00:23,470
I'm not going to refresh the page and take a look at the request to get my list of streams from the

8
00:00:23,500 --> 00:00:30,330
slash streams and point on my API when I select that request or then open up response right here or

9
00:00:30,340 --> 00:00:34,180
preview either one inside of this list of streams.

10
00:00:34,270 --> 00:00:37,510
Here's my Stream right here I've got the title and the description.

11
00:00:37,750 --> 00:00:39,060
I've also got the idea.

12
00:00:39,370 --> 00:00:45,100
Remember we only show those edit and delete buttons if the user id of the stream is equal to the currently

13
00:00:45,100 --> 00:00:46,740
signed in user.

14
00:00:47,020 --> 00:00:49,470
So I don't see any user ID right here.

15
00:00:49,750 --> 00:00:52,120
So something seems a little bit off.

16
00:00:52,360 --> 00:00:55,270
Well let me just come out and tell you exactly what's going on here.

17
00:00:55,300 --> 00:01:00,610
I want you to see this little air right here to kind of clean clear up a very common misconception in

18
00:01:00,610 --> 00:01:05,030
the world of rest requests restful requests are restful conventions.

19
00:01:05,280 --> 00:01:05,670
All right.

20
00:01:05,670 --> 00:01:08,070
So I showed you this chart a while ago right here.

21
00:01:08,260 --> 00:01:10,480
MEMBER We spoke about restful conventions with this.

22
00:01:10,480 --> 00:01:15,400
We spoke about how we can make a get request to streams to get a list of all of our records.

23
00:01:15,400 --> 00:01:20,410
We spoke about making a post request to stream's to create a record and then I had told you that to

24
00:01:20,500 --> 00:01:26,260
update a record we were going to make a polite request to stream's slash and then the ID stream that

25
00:01:26,260 --> 00:01:27,900
we were trying to update.

26
00:01:28,000 --> 00:01:33,490
Now a lot of documentation you're going to read is going to say exactly that but a put request actually

27
00:01:33,490 --> 00:01:35,430
has a little side effect to it.

28
00:01:35,500 --> 00:01:39,900
That is very commonly not well implemented in a lot of back and API.

29
00:01:40,120 --> 00:01:43,520
So here's what really goes on when you make a put request.

30
00:01:43,810 --> 00:01:49,330
The actual thing that happens is whatever properties you put inside the body of that request are going

31
00:01:49,330 --> 00:01:54,220
to replace all the properties inside of the record that you're trying to update.

32
00:01:54,220 --> 00:02:00,460
So in other words when we just made our update request were are put requests on submission that form.

33
00:02:00,670 --> 00:02:03,840
We posted the title and description property right.

34
00:02:03,850 --> 00:02:08,290
We just made a big deal about saying that we were only going to take the title and the description out

35
00:02:08,290 --> 00:02:12,320
of the form and attempt to submit that to the back end API.

36
00:02:12,460 --> 00:02:18,490
The problem is that when we made our request to our API the API said oh OK I see a title and description

37
00:02:18,670 --> 00:02:23,410
and I see you made a put request so I'm going to take all the different properties inside the stream

38
00:02:23,650 --> 00:02:28,290
the title The ID the description and the user id as well.

39
00:02:28,390 --> 00:02:34,340
And I'm going to replace them with just the properties that you posted or put up to this API.

40
00:02:34,540 --> 00:02:40,570
So we put a tile and description that meant that we took the existing title description and user ID

41
00:02:40,780 --> 00:02:44,380
and replace it with just the new title and description.

42
00:02:44,380 --> 00:02:48,410
The one property that is usually immune to this is the id property.

43
00:02:48,430 --> 00:02:53,770
So essentially when we made our Put request we did not include a user ID inside of that update and we

44
00:02:53,770 --> 00:02:56,060
did that for very good reasons that we just discussed.

45
00:02:56,200 --> 00:03:02,230
But our back and AAPI interpreted that as saying oh you no longer want a user ID and so it just dropped

46
00:03:02,230 --> 00:03:03,960
off the user id entirely.

47
00:03:04,150 --> 00:03:08,620
And that's why we don't see the User ID associated with our request here anymore.

48
00:03:09,500 --> 00:03:14,240
So again I wanted you to see this I want you to run into this problem because a lot of people kind of

49
00:03:14,450 --> 00:03:19,030
designed these put request routes on back and servers in different ways.

50
00:03:19,070 --> 00:03:23,750
You're technically supposed to make sure that a put request is going to replace or update all properties

51
00:03:23,750 --> 00:03:28,730
of a record which could potentially lead to deleting properties off a record on the API.

52
00:03:29,240 --> 00:03:33,830
If you really want to just update some properties we're actually supposed to use a different type of

53
00:03:33,830 --> 00:03:40,460
request called a patch request so that the Patrick Quest we're going to pass some properties inside

54
00:03:40,460 --> 00:03:43,700
the body the request that are supposed to be updated on the API.

55
00:03:43,940 --> 00:03:47,500
And with a patch request just those properties are going to be updated.

56
00:03:47,510 --> 00:03:52,970
It's not essentially an overriding operation that's going to cause some properties to be dropped off.

57
00:03:53,000 --> 00:03:59,280
So let's try updating our action creator to make a patch request as opposed to a puts.

58
00:03:59,330 --> 00:04:04,250
So I going to go back over to my actual creator file to find at it Stream right here and essentially

59
00:04:04,250 --> 00:04:08,690
all you have to do is rather than calling put right here to make a point type request we're going to

60
00:04:08,690 --> 00:04:10,890
make a patch request instead.

61
00:04:10,910 --> 00:04:11,680
That's it.

62
00:04:13,480 --> 00:04:18,100
So now when we make a Patrick quest to our back in API with form values we're just going to be updating

63
00:04:18,100 --> 00:04:24,790
the form values on our API and we're not going to destroy or unset any properties with our stream because

64
00:04:24,790 --> 00:04:27,540
we were making the request before.

65
00:04:27,700 --> 00:04:30,970
So let's flip back over to our application and we'll test this out really quickly.

66
00:04:33,730 --> 00:04:39,070
Now this time I'm going to attempt to edit this Stream right here so click on edit and all change the

67
00:04:39,070 --> 00:04:39,930
description of it.

68
00:04:39,940 --> 00:04:47,920
I'll say this change was made by a patch request and then I will submit this.

69
00:04:47,920 --> 00:04:52,570
Now inside my requests log right here you can see that I'm now making a patch request so I can select

70
00:04:52,570 --> 00:04:58,570
that I see the response right here and the response has the new description as the same title.

71
00:04:58,600 --> 00:05:00,330
It has my user ID.

72
00:05:00,340 --> 00:05:04,320
Most importantly so I did not overwrite the user ID.

73
00:05:04,540 --> 00:05:09,700
And now when I go back to a list of streams I still see the edit and delete buttons as I would expect

74
00:05:09,850 --> 00:05:11,790
whenever I edit a stream.

75
00:05:12,280 --> 00:05:13,240
Ok guess that's pretty much it.

76
00:05:13,240 --> 00:05:17,950
Again I want you to see this issue because you're going to see a lot of conflicting API is where sometimes

77
00:05:17,950 --> 00:05:22,600
if you make the request it's going to drop off some properties and in those cases you're supposed to

78
00:05:22,600 --> 00:05:23,700
use patch instead.

79
00:05:23,860 --> 00:05:29,170
But a lot of people choose to just kind of disregard this rule when they are designing API or back and

80
00:05:29,170 --> 00:05:29,810
servers.

81
00:05:29,920 --> 00:05:34,270
A lot of people just say oh yeah just make a put request in the back end server or we'll just merge

82
00:05:34,270 --> 00:05:37,830
these different properties as opposed to dropping some off as we just saw.

83
00:05:38,180 --> 00:05:41,770
I guess now that we've got this all fixed up let's take a quick pause right here and we'll continue

84
00:05:41,800 --> 00:05:42,580
in the next video.