1 00:00:00,450 --> 00:00:03,780 Instructor: Our next verb is the PUT verb. 2 00:00:03,780 --> 00:00:07,230 Now, the PUT verb is quite similar to the POST 3 00:00:07,230 --> 00:00:10,860 but there is one very important different. 4 00:00:10,860 --> 00:00:15,690 The PUT verb is used to modify resources. 5 00:00:15,690 --> 00:00:19,830 If you remember, POST is used to add resources 6 00:00:19,830 --> 00:00:23,220 and PUT is used to modify them. 7 00:00:23,220 --> 00:00:26,130 So, if you remember the CRUD acronym 8 00:00:26,130 --> 00:00:28,470 we mentioned at the beginning of this section, 9 00:00:28,470 --> 00:00:32,880 the CRUD that stands for Create, Read, Update and Delete. 10 00:00:32,880 --> 00:00:36,030 Then POST is used for the create 11 00:00:36,030 --> 00:00:39,330 and PUT is used for the update. 12 00:00:39,330 --> 00:00:40,860 The rest of what you need to know 13 00:00:40,860 --> 00:00:43,050 about the PUT verb is quite similar 14 00:00:43,050 --> 00:00:46,105 to what we said about POST. 15 00:00:46,105 --> 00:00:48,360 A PUT request should contain a message body 16 00:00:48,360 --> 00:00:51,450 that specifies the resource to be modified. 17 00:00:51,450 --> 00:00:55,140 A PUT request should not contain queries from parameters, 18 00:00:55,140 --> 00:00:57,150 and you see an example here. 19 00:00:57,150 --> 00:00:59,010 So, in this example you should not 20 00:00:59,010 --> 00:01:02,340 include the company equals 15 parameters. 21 00:01:02,340 --> 00:01:06,540 Again, because it's quite similar to the POST verb. 22 00:01:06,540 --> 00:01:09,690 So, having say that, let's see a short demo 23 00:01:09,690 --> 00:01:12,210 of how to implement the PUT verb. 24 00:01:12,210 --> 00:01:16,740 So, here we have our Beeceptor, our loyal Beeceptor. 25 00:01:16,740 --> 00:01:19,200 And again, let's click the mocking rules 26 00:01:19,200 --> 00:01:21,993 and let's create a new rule. 27 00:01:23,010 --> 00:01:26,370 And I guess you can guess already what's gonna happen. 28 00:01:26,370 --> 00:01:28,860 We will select here PUT. 29 00:01:28,860 --> 00:01:33,693 Here, we will type API and order, 30 00:01:34,650 --> 00:01:39,453 And in the status, we will just modify it to Updated. 31 00:01:40,680 --> 00:01:42,960 Sorry, Updated. 32 00:01:42,960 --> 00:01:46,560 Great, and the status will be 200 as usual 33 00:01:46,560 --> 00:01:48,840 and let's save this rule. 34 00:01:48,840 --> 00:01:51,960 Now, look at this list of the APIs. 35 00:01:51,960 --> 00:01:53,986 You can see that apart from the first one 36 00:01:53,986 --> 00:01:55,920 that we used as a test, 37 00:01:55,920 --> 00:02:00,420 all the other API have the same URL with API order. 38 00:02:00,420 --> 00:02:02,910 The only different between them is the verb 39 00:02:02,910 --> 00:02:05,787 This is the GET, the POST, and the PUT. 40 00:02:05,787 --> 00:02:07,980 And from the REST API point of view, 41 00:02:07,980 --> 00:02:10,562 these are a completely different APIs. 42 00:02:11,670 --> 00:02:13,593 Okay, so now let's go to Postman, 43 00:02:14,608 --> 00:02:19,560 and we will simply modify the verb here 44 00:02:19,560 --> 00:02:24,560 and instead of POST, we will go to PUT and that's all. 45 00:02:25,380 --> 00:02:28,830 Now, you remember that when testing the POST verb, 46 00:02:28,830 --> 00:02:31,860 we've got the Status Created response. 47 00:02:31,860 --> 00:02:34,890 So, now I've only changed the verb, 48 00:02:34,890 --> 00:02:38,395 and let's click send and see what happens. 49 00:02:38,395 --> 00:02:41,460 And we've got the updated status, 50 00:02:41,460 --> 00:02:44,490 which is exactly what we wanted to get. 51 00:02:44,490 --> 00:02:46,920 And, of course, the status is 200, 52 00:02:46,920 --> 00:02:50,040 just as we defined in Beeceptor. 53 00:02:50,040 --> 00:02:53,760 So, as you can see, PUT and POST are very similar. 54 00:02:53,760 --> 00:02:55,260 And the only difference between them 55 00:02:55,260 --> 00:02:58,680 is that POST is used to add resources 56 00:02:58,680 --> 00:03:02,100 and the PUT is used to modify resources. 57 00:03:02,100 --> 00:03:04,170 Now, let's go back to the slide 58 00:03:04,170 --> 00:03:06,360 because there are some interesting topics 59 00:03:06,360 --> 00:03:08,190 to discuss about PUT. 60 00:03:08,190 --> 00:03:10,950 So, what do you think should happen 61 00:03:10,950 --> 00:03:15,300 if I put a resource but the resource does not exist? 62 00:03:15,300 --> 00:03:18,510 How can I update a non-exist resource? 63 00:03:18,510 --> 00:03:20,670 What should I do in this case? 64 00:03:20,670 --> 00:03:24,120 So, the specification states that in this case 65 00:03:24,120 --> 00:03:26,040 a new resource should be created. 66 00:03:26,040 --> 00:03:27,690 In other words, in this case 67 00:03:27,690 --> 00:03:30,930 the PUT should behave just like POST. 68 00:03:30,930 --> 00:03:34,320 But to be frank, you can use your own discretion. 69 00:03:34,320 --> 00:03:36,450 You can also choose to return some kind 70 00:03:36,450 --> 00:03:39,210 of error message stating that you cannot update 71 00:03:39,210 --> 00:03:40,590 a non-exist resource. 72 00:03:40,590 --> 00:03:43,140 So, again, do whatever feels right for you 73 00:03:43,140 --> 00:03:44,550 in this specific context. 74 00:03:44,550 --> 00:03:48,600 One of the most important definition of the PUT verb 75 00:03:48,600 --> 00:03:50,430 and one that is often ignored 76 00:03:50,430 --> 00:03:53,760 is that PUT should be Idempotent. 77 00:03:53,760 --> 00:03:56,400 Now, if you're not familiar with this term Idempotent, 78 00:03:56,400 --> 00:03:57,900 then let's explain it a bit. 79 00:03:57,900 --> 00:04:00,150 What Idempotent means that 80 00:04:00,150 --> 00:04:03,210 if we have some kind of action or a method, 81 00:04:03,210 --> 00:04:06,960 then no matter how many times we execute this method, 82 00:04:06,960 --> 00:04:09,840 the result will always be the same. 83 00:04:09,840 --> 00:04:12,000 Now to understand it fully, 84 00:04:12,000 --> 00:04:15,000 let's talk a little bit again about the POST. 85 00:04:15,000 --> 00:04:18,570 If we are sending a POST request to create an entity, 86 00:04:18,570 --> 00:04:20,399 then an entity is created. 87 00:04:20,399 --> 00:04:24,120 And if we send the exact same POST to the server, 88 00:04:24,120 --> 00:04:25,260 what happens? 89 00:04:25,260 --> 00:04:28,950 So, in this case we will have two identical entities. 90 00:04:28,950 --> 00:04:30,840 Well, probably not really identical, 91 00:04:30,840 --> 00:04:34,650 probably the ID or the key of the entity will be different 92 00:04:34,650 --> 00:04:38,070 but the entities themselves will be identical. 93 00:04:38,070 --> 00:04:41,730 So, we can see that post is not it Idempotent 94 00:04:41,730 --> 00:04:45,210 because the number of the entities that will be created 95 00:04:45,210 --> 00:04:49,110 is identical to the number of the POST request I send. 96 00:04:49,110 --> 00:04:52,890 However, with the PUT, the behavior is quite different 97 00:04:52,890 --> 00:04:56,430 because no matter how many PUT request I send 98 00:04:56,430 --> 00:04:58,770 there is always a single entity. 99 00:04:58,770 --> 00:05:03,270 So, with PUT, I can be sure that the data is consistent 100 00:05:03,270 --> 00:05:06,780 and no redundant entities were created using my code. 101 00:05:06,780 --> 00:05:10,830 So, when you write the code that implements the PUT verb, 102 00:05:10,830 --> 00:05:13,860 always remembers that PUT should be Idempotent. 103 00:05:13,860 --> 00:05:16,380 And no matter how many times the request, 104 00:05:16,380 --> 00:05:18,870 the PUT request is executed, 105 00:05:18,870 --> 00:05:20,700 the data is always consistent 106 00:05:20,700 --> 00:05:22,923 and no redundant data is created.