What all different ways can you display foreign key relationships?
For now I think I'm done with API views. 0:00 There are a couple more topics I want to touch on though before I get to 0:03 securing the API. 0:05 The review model has a foreign key relationship to a course. 0:06 Currently with the API the user has to go to the special reviews url to 0:11 see the reviews for a specific course. 0:14 What if instead I just included all of the reviews with the course. 0:16 Or I might want to list the foreign keys to those reviews with each course. 0:20 Maybe I could have a list of URLs to each review instead. 0:24 Each of these approaches is possible and each has potential benefits and drawbacks. 0:28 So I'm here in courses Serializers.py and the first 0:33 option I want to look at is the idea of nested relationships and this is where 0:38 there are related records that need to be included inside of a particular resource, 0:43 which is kind of like, well it's how reviews should show up in course records. 0:47 You can use the review Serializer as a field on the course Serializer and 0:53 this causes full reviews to be populated into the course data. 0:58 So let me let me show you how to do that. 1:02 So down here in the course Serializer I'm going to add a new 1:03 attribute here that's called Reviews and it's gonna be ReviewSerializer. 1:07 It's going to be many equals true and read only 1:14 equals true and if you looked at the models you know that reviews 1:19 is the reverse relationship name between a review and a course. 1:23 So it just it's going to take that right that bit of data and 1:28 we now of course have to add reviews to our list of fields. 1:32 Okay so let's see what this does. 1:38 So come back over here and let's do courses one. 1:42 Actually this is two courses and here we go Python basics. 1:46 The reviews it has one review which is this one from 1:50 this lovely person named Kenneth, and then these two don't have any reviews yet, so 1:53 we get just an empty list for the reviews. 1:58 So, great. 2:01 That's pretty awesome. 2:03 So this works, it's good. 2:04 There is a drawback though. 2:06 What happens when this course here, or 2:08 any of these courses, have thousands of reviews. 2:12 What happens when there are thousands of courses that have thousands of reviews. 2:15 The amount of time it takes the API to respond is just going to increase. 2:19 It's gonna get bigger and bigger and 2:23 bigger the more data they get sent back to the client. 2:24 Things could go downhill really fast and I don't want that to happen. 2:27 So this type of approach works really well. 2:32 It works better when you know that you have a limited amount of data 2:35 that's gonna be displayed. 2:39 There's a certain amount of data that's gonna come out. 2:40 Nothing else is ever gonna come out. 2:42 Like a one-to-one relationship, where one user has one profile. 2:44 That's great, that's fine, because it's only ever gonna be 2:49 two records that come out, one user and one profile at any given time. 2:51 So that's awesome. 2:55 That's not what we have here though. 2:57 Here I have as many things as possible. 2:58 So, let me show you another one, which is the hyperlinked related field. 3:02 So back over here in Serializers and 3:06 here instead of review Serializer I'm gonna say 3:10 serializer.Hyperlinked link 3:14 not liked RelatedField capital F Field. 3:19 All right it's still many equals true it's still read only. 3:25 But now it has a new attribute, which is view_name, or new argument rather. 3:30 And I'm gonna say apiv2, which is the namespace. 3:35 And review-detail, which is the automatically generated view name for 3:39 the view set in the router. 3:44 Cool. 3:47 Okay, so now let's go refresh this. 3:48 And now what's cool is I have reviews and I just have a link here to a review. 3:51 And I'm wanna Command+click that opens in a new tab and there's that review. 3:55 So this is actually what's recommend you here 4:00 when people talk about APS, I talk about Hiteioas. 4:05 H-I-T-E-I-O-A-S which nobody really reads into how you say that. 4:09 Anyway the idea is that things are always hyperlinked to each other. 4:13 You don't include a huge amount of data that you don't need to include 4:16 when they can go get it at another end point. 4:19 So you send them off to that other end point. 4:22 They get the data they need and then they do whatever they need to do. 4:24 So that's great that's really cool. 4:29 Again this is a really good and decent solution but 4:32 if you have thousands of reviews for even one of your resources. 4:35 This could start just drastically increase in the API 4:40 response time because Django has to go and 4:43 create those URLs for every single one of those reviews so pros and cons. 4:45 Let me let me show you one last possibility here which instead of 4:50 the hyperlink related field, we're going to change hyperlink here to primary, 4:54 primary key related fields and we don't need that 5:00 view name anymore it can just be mean equals true and read only equals true. 5:05 So come back over here refresh and now I just have one. 5:10 So just the ID is is one. 5:15 This is probably the best this is probably the fastest option because all it has do 5:17 is go grab that injure every single time right it just goes and gets that primary 5:21 key you can get primary keys you can get integers out of it's really fast. 5:24 So this is great if you can expect your users to somehow know that URL. 5:29 Maybe you add in a reviews URL link that will tell them what that is and 5:34 they can just append the one or the fifteen or the two thousand and 5:39 eighty two or whatever onto the end of it that's going to depend on your API so 5:43 I'll let you make those decisions yourselves. 5:47 Personally, I really like the hyperlinked one especially when I'm using 5:50 the browsable API because that way I can just click around and 5:53 go see what all my stuff is. 5:55 But again, it's totally going to depend on your API and your API's needs. 5:57 As you've seen, you have a lot of options for how to serialize related records. 6:03 I recommend looking over the full documentation for 6:07 Serializer relationships. 6:09 So I put a link in the teacher's notes. 6:10 You can get very specific with the way that you handle relationships on your 6:12 serializer, so it's good to know your options and the potential drawbacks. 6:15 Try them out test them with unit tests and 6:19 load testing tools if you're curious how they perform. 6:21 For this project though, I think it makes the most sense to keep the reviews 6:24 on a separate API view which is already in place. 6:27
You need to sign up for Treehouse in order to download course files.Sign up