DRF Request - A Gentle Introduction - Part One
An analogy of DRF Request that one can think of is when you are going to buy an item at a shop. You present your claim by first introducing yourself to the shopkeeper. The shopkeeper will then optionally accept your order and optionally sell you what you want.
Moreover, the shopkeeper can package the content in a way that you want, for example wrapped in a bag, wrapped in a box or you can even choose to carry it on your own packing. After that, you can then pay using one of the available payment options you saw. That basically summarizes what a DRF Request is and this is the analogy we are going to be using in this article. So sit tight and let’s get started!
Reading the room.
First and foremost, you will need to first check and see if the prerequisite for you to have a successful purchase are met. For example, you will need to first see if the option of payment you have is acceptable by the shopkeeper. Well, if it is, then check for things like packaging option, whether the shopkeeper offers packaging option for perishable goods or will you be carrying your grocery by hand all the way home. This is one of the qualifications which will either make you go on with the request or return and come back with a better option. So this is basically part of DRF Request Basics.
Similarly, the same applies to a DRF request through content negotiation. This is what determines whether the client request is able to be served by the existing set up on the server. This can be using accepted_renderer and accepted_media_type for example. Has the user presented the right data? Can the available renderers handle the request data provided? Well, if all is well, then it is time to make contact.
Making contact.
So, the next thing is to make contact, and here you will get to present your claim to the shopkeeper. In this part of this DRF request tutorial, this is what we are going to be taking a look at.
The first scenario is when you are new in that location, or you find a different seller this time round? Well, there has to be some trust that needs to be established before anything can proceed don’t you think? And with that, we have authentication. You will need to convince the shopkeeper that, “hey, we may not have met before, BUT I check out as a credible person”. So, depending on the required details, then the shopkeeper will decide whether to agree and sell to you or withdraw their service, since they are not convinced you are who you claim to be and he/she does not want to get into trouble with the authorities. However, if you check out, then all is well and the shopkeeper can proceed with selling to you.
The other scenario can be where you are a returning customer and well, you and the shopkeeper trust each other and so you immediately earn his/her trust and they can sell to you. So, you can think of this as a session of trust between you and the shopkeeper, that lasts as long as you two can identify each other, and is voided once you two seem to not clearly identify one another, for example if you decide to get a face tattoo one day, in which case you will seem different to the shopkeeper!
A similar situation happens when you are making a DRF request to a web-server from your client. You will need to authenticate yourself with the server, so that there is a trust established between the two of you. This will be obtained from request.user which will return either the authenticated user, or AnonymousUser. Along these lines, it will be dependent on the django rest framework authentication scheme in place. This can be done globally using REST_FRAMEWORK.DEFAULT_AUTHENTICATION_CLASSES or on per view basis using @authentication_classes decorator. This is a list of the authentication schemes which are in place to mention but a few:
- BasicAuthentication
- SessionAuthentication
- TokenAuthentication
Moreover, if there is the option for token based authentication, then request.auth will provide the authentication context and avail the token as well. So, this token is like a “memory” which the shopkeeper (server) uses to remember each of their customers (clients)
So, now that enough trust has been established between you two, it is time to make your purchase, BUT is it, is it though? We now finalize this short paced DRF request tutorial, and I hope that you picked a thing or two from it. In the next part of this DRF Request basics series, we will be taking a look at the DRF request authorization, and it will be amazing