1 00:00:00,660 --> 00:00:04,290 Narrator: So what exactly is HATEOAS? 2 00:00:04,290 --> 00:00:07,320 So HATEOAS is an acronym stands for 3 00:00:07,320 --> 00:00:12,320 hypermedia as the engine of application state. 4 00:00:12,630 --> 00:00:17,520 And what this means is that when calling REST API 5 00:00:17,520 --> 00:00:21,060 and getting back a response, an entity, 6 00:00:21,060 --> 00:00:26,010 then the entity already contains all the related resources, 7 00:00:26,010 --> 00:00:29,100 or all the pointers to the resources 8 00:00:29,100 --> 00:00:31,590 that you might be interested in. 9 00:00:31,590 --> 00:00:35,219 So for example, if the API returns user entity 10 00:00:35,219 --> 00:00:38,700 and this user has some orders, 11 00:00:38,700 --> 00:00:41,280 then in order to get those orders 12 00:00:41,280 --> 00:00:46,200 the client would not need to call a separate API for orders, 13 00:00:46,200 --> 00:00:50,310 but the user entity will have pointers to those orders. 14 00:00:50,310 --> 00:00:53,850 So using this pattern, the client should not have any 15 00:00:53,850 --> 00:00:56,340 prior knowledge about other resources. 16 00:00:56,340 --> 00:01:00,720 The only thing the client should know is the first API, 17 00:01:00,720 --> 00:01:01,920 the route endpoint, 18 00:01:01,920 --> 00:01:03,570 and after calling this endpoint 19 00:01:03,570 --> 00:01:06,120 then all the other related resources 20 00:01:06,120 --> 00:01:09,210 are already contained in the route entity. 21 00:01:09,210 --> 00:01:12,033 So let's see an example of implementing HATEOAS. 22 00:01:14,370 --> 00:01:18,900 So for our example, I would like to introduce you to Genie. 23 00:01:18,900 --> 00:01:21,919 Genie is a software made by Netflix 24 00:01:21,919 --> 00:01:25,560 and this is basically an open source distributed 25 00:01:25,560 --> 00:01:28,530 job orchestration engine, so you can think 26 00:01:28,530 --> 00:01:32,850 of it as a giant scheduler that schedules various jobs 27 00:01:32,850 --> 00:01:37,608 and monitors them and makes sure that everything works fine. 28 00:01:37,608 --> 00:01:39,840 Now for our example, it doesn't really matter 29 00:01:39,840 --> 00:01:41,040 what Genie is doing, 30 00:01:41,040 --> 00:01:45,270 but the interesting part for us is Genie's API. 31 00:01:45,270 --> 00:01:49,650 So let's take a look at the REST API exposed by Genie. 32 00:01:49,650 --> 00:01:51,750 So this is Genie's API 33 00:01:51,750 --> 00:01:54,390 and as you can see we are currently looking 34 00:01:54,390 --> 00:01:56,940 at an API that gets a job 35 00:01:56,940 --> 00:01:59,580 which means this API when calling this API, 36 00:01:59,580 --> 00:02:01,380 and you can see here is the endpoint, 37 00:02:01,380 --> 00:02:04,110 and you can also see that this endpoint is structured 38 00:02:04,110 --> 00:02:06,870 exactly as we discussed with the API, the version, 39 00:02:06,870 --> 00:02:09,120 and the entity, then this API gets 40 00:02:09,120 --> 00:02:12,150 the metadata about a specific job. 41 00:02:12,150 --> 00:02:13,920 Now let's scroll down 42 00:02:13,920 --> 00:02:18,390 and take a look at what is the response for this API. 43 00:02:18,390 --> 00:02:21,120 So after asking for a specific job, 44 00:02:21,120 --> 00:02:23,760 as you can see here this is the ID 45 00:02:23,760 --> 00:02:25,590 of the job we want to retrieve, 46 00:02:25,590 --> 00:02:27,850 then this the response, this is the status code, 47 00:02:27,850 --> 00:02:32,580 and these are the various properties of the job 48 00:02:32,580 --> 00:02:34,350 we can see when it was created, 49 00:02:34,350 --> 00:02:36,845 when it was updated, what is it's version, 50 00:02:36,845 --> 00:02:39,930 the name of the job, and so on. 51 00:02:39,930 --> 00:02:44,930 And if we scroll down we will see this links section. 52 00:02:45,720 --> 00:02:50,580 So as you can see, the links section contains, well, links 53 00:02:50,580 --> 00:02:52,680 to other entities that might be relevant 54 00:02:52,680 --> 00:02:54,210 if you want to use Genie. 55 00:02:54,210 --> 00:02:58,110 So we have a link to self, which is the entity itself 56 00:02:58,110 --> 00:03:01,530 and to the output and the request and execution and 57 00:03:01,530 --> 00:03:04,740 more data and entities related to this specific job. 58 00:03:04,740 --> 00:03:08,130 So for example, if I retrieved this job and now I want 59 00:03:08,130 --> 00:03:12,030 to know it's status, here I don't need to look 60 00:03:12,030 --> 00:03:15,390 into the documentation for an API returning status. 61 00:03:15,390 --> 00:03:18,600 I can look at the entity itself, at the job entity, 62 00:03:18,600 --> 00:03:21,940 and go to that status link which is right here 63 00:03:21,940 --> 00:03:24,750 and simply access this API. 64 00:03:24,750 --> 00:03:27,930 So this API is already constructed for me 65 00:03:27,930 --> 00:03:32,520 for this specific job and it returns the status of this job. 66 00:03:32,520 --> 00:03:35,280 Now if you scroll up a little in the documentation 67 00:03:35,280 --> 00:03:39,150 then you can see that right here the documentation 68 00:03:39,150 --> 00:03:41,670 mentions HATEOAS specifically. 69 00:03:41,670 --> 00:03:44,850 So the HATEOAS is built into the API 70 00:03:44,850 --> 00:03:47,370 and from Genie's point of view this is definitely 71 00:03:47,370 --> 00:03:49,260 something that should be used. 72 00:03:49,260 --> 00:03:52,290 So again in short, HATEOAS is a pattern 73 00:03:52,290 --> 00:03:54,862 that returns all the related entity's links 74 00:03:54,862 --> 00:03:58,260 in the route entity so that the client should not 75 00:03:58,260 --> 00:04:01,170 have any prior knowledge about the endpoints 76 00:04:01,170 --> 00:04:02,613 of related entities.