DRF Request - A Gentle Introduction - Part Two
So, following on from the previous DRF request tutorial, in this part we will be taking a look at what happens after you have made contact and proven to the server (shopkeeper) that you are indeed who you claim to be.
Without further ado, let's proceed with the next two concepts on DRF request basics:
- Can you be allowed to make your purchase?
- Now it is time to present your shopping list.
Are you permitted to make your purchase?
Let’s just assume you are under age and are not allowed to buy alcohol, well, just because trust has been established between you and the shopkeeper, you will need to have the right rights to purchase the right item (a mouthful of ‘rights’, but it is best so that you remember).
This means that you have to be authorized to make the purchase for a given item. So, analogous to the above example, a similar situation happens with DRF request authorization. This is done by retrieving the authenticated user, if any, from request.user, and this returns the User Object.
Then on this user, authorization is done to check if they have the correct rights to access the endpoint that they want to. This ensures data protection and enforces that clients get what they are allowed to get!
It is that simple to to DRF request authorization! All you need is to get the user, then after that, you can do all sorts of authorization checks on that specific user. Some of the DRF request authorization checks you can make are:
- Is the user an admin?
- Is the user of the right age to access requested content?
- Is the user account activated?
- Has the user renewed their membership?
The list is endless and the possibilities of DRF request authorization are endless.
So, now you can present your shopping list.
So, for this part of this DRF request tutorial, we will be looking at how you present your data to the server. Or in other words, we are gonna be going for some shopping!
We all have that shopping list, and we treasure it so much. We have a list of all the items which we want to purchase, and it is what we present to the shopkeeper.
However, not all the times will the shopkeeper be able to understand what we are presenting and in this case, there can be a miscommunication, BUT we know that it is what we want, well, shopkeeper will have no choice but to tell us that the item is not there, due to miscommunication of what we want. For example we may say that we want 1 liter of maize flour! This clearly is wrong and the shopkeeper will have no choice but to deny such a sale.
A similar case happens with a DRF request, there are parsers which determine whether the client request is a valid one and if it actually makes sense, before even trying to process it. If it does not make sense, then this is caught up before further damage can be done and blocked from proceeding. For example, sending a malformed JSON will result in a Bad Request being sent back, meaning that the server is not able to handle the DRF request as presented.
So, assuming that you have a valid claim and request, then you can now make a purchase of what you want. Usually, you would have just gone with everything crammed up in your brain or you would have written them down on a list and even have some sketches for further explanations.
So, analogously, you can present query_params (cramming the list) or you can present data (writing the list down). Clearly cramming the list is not a feasible option, since it is so limited because of a number of reasons:
- It is hard to remember.
- There is a chance to make a mistake.
- It is not reliable nor is it presentable.
- It is limited to things like not being able to explicitly draw the image of what you want.
- It takes time to say what you want by getting it from memory. For example if you are asked how many eggs you want, you can easily confuse it with how many pegs you want?
So, if you are to use query_params option, use it for where the intention is limited. That is, use it when you want to buy just a few items.
On the other hand, writing the list down is clearly a better option since it:
- Is more reliable.
- Easy for shopkeeper to understand.
- Very flexible
- You cannot miss out on anything you wanted.
- There is no room for mistakes. I mean, you cannot compare the above list with the cramming one!
- Many more benefits you can think of :-)
So, you would use data option when you are dealing with multiple content that needs to be more flexible. This you can get from request.data and it will give you the data as you need it.
So, this concludes the second part of DRF request tutorial, from here, you have learn:
- How to authorize DRF request.
- How to get data from DRF request.
So, onto the next fun part! Hold onto your mouse, it is going to be awesome!