Here, we will be talking about what is generally known as content negotiation when resolving a DRF request. So you may be wondering what is content negotiation? Well, long story short, content negotiation is presenting data in the most appropriate way depending on the request.
So, we will continue from where we left off in the previous tutorial, and now handle returning data to the client from the incoming DRF request. Analogously, how the shopkeeper will be packaging your purchases!
So, you have your shopping done and everything is already picked from the shelf. The shopkeeper will then ask you how you wish to have the contents packed, then he/she will do that for you. However, at times, you will find that the option of packing that you want is not there, in which case, the shopkeeper will use the normal packaging option available.
In a DRF request, this is what is called content negotiation. It is a way the server uses to decide on how it will return the data to you, based on how you made the DRF request. This normally depends on both the configuration on the server and the request of the client. Think of it as a team effort between client and server.
So, the server will check and see what is the best way to present the provided data, just like how the shopkeeper finds the best way to package an item. Also, the client has the right to say how they want the data to be provided for them.
Basically, think of DRF content negotiation as the process of determining the most appropriate way to send back data to the client which made the DRF request.
Now it is time to make your payment, well, this can be a tricky one, what if the shopkeeper does not accept my means of payment? Well, remember when you came to the shop, you saw the available options of payment, so, whatever the options available, you selected one in your mind and you now know that you will be using it to pay. Think of this as accepted payment option. Basically, it is either accepted or not, and it cannot be both.
This is something which both you and the shopkeeper can agree on, which means that if your means of payment is not listed as an available option, then you cannot get service and hence need to return with a viable payment option. But this was all prevented at the start, when you saw all available options and knew that your option is there on the list. The worst that can happen is that you can go empty handed, and possibly be banned and even fined for time wasting!
So, this is what happens as well with DRF request content negotiation when it comes to. A DRF request will avail some configurations like parsers which will make you know how to proceed with the rest of the request or to bail and return with an alternative request, with a format that can be parsed.
It will also provide accepted_renderer or accepted_media_type that help you know the format of the response data to expect. Also, just to make you smile, you cannot be fined, the worst that can happen is that you do not get the response data, and just an error response.
So, you have now successfully completed this awesome (I hope it was) DRF request tutorial. As you can see, DRF Request is such a helpful tool and makes dealing with REST APIs very easy.
All you need to do is to shift your thinking from HTML Form to JSON format, with request.data as the common ground, and that is it! All other delicacies like request.auth e.t.c are just to make DRF requests even more robust.
So, you have read everything and are now ready to take on the world of DRF Requests. Please feel free to share this content with your friends.
Also let me know what you think about this method of presenting content.
Thanks!