Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have been using in one of my views request.data instead of serialzer to get json data and work on it, my question is this ok or lets say "a good practice" to use request.data or should i create serializer class for that view?
The reason to use a serializer in the first place is to transform native python data types to valid JSON and vice-versa. Consequently, the serializer adds a layer of validation to make sure that this transformation process runs correctly in accordance with your serializer definition.
If you decide to omit the serializer in the views, you would have to handle data validation there yourself and you end up implementing a feature which already exists in practice and has been "battle-tested" and worked on by multiple accomplished developers. There are cases where you don't strictly need a serializer in your views, for example when you simply display data from another source and only allow GET requests, but whenever you deal with data input I would consider it bad practice to not use serializers.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I need something to view the queries happened ( creating or updating or deleting ) in DB tables in Django, I want it to be able to be used by the user, not at the admin panel
If I understand your question correctly, you are looking for a model history (sometimes also called "audit trail").
In this link there is a comparisson of different packages that can be used for audit/history of models.
As I already pointed out in this answer,
I use django-simple-history which comes with a nice integration to view the list of changes of every model instance in the admin.
For my use case at least, django-simple-history provided me with what I needed, and so far I did not face any issues with it, even though this package does NOT track history of ManyToManyField (for that see related questions like this or this or the Github issue).
Now, if you want the end user to be able to see the history (but not through the admin panel), then you would need to add a few pages for that.
For example, you could add a list view for each model using djangos generic ListView.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I read about REST API specifications. These are the principles:
everything is a resource
each resource is identifiable by a unique identifier
use the standard HTTP methods
Now suppose there is a table for contact details
id , owner, contact name,contact number, created At
I want to design an API to consume the data. I can design the api in the following ways.
For getting the contact by owner
Get /contact/owner/david
or
Get /getContactByOwner?ownerName="david"
For writing into the table
post /contact/owner
{contactDetail JSON in request param}
or
post /addToContact?owner="john"&...
Which design is RESTful? What is wrong with the other one?
The rule of thumb with RESTful naming conventions is to use nouns as your endpoints (since your verbs should be limited to get / post / put / delete / etc). So in your example, Get contact/owner/david and Post contact/owner would be preferable. However, if you're really using REST architecture, you should technically be using HATEOAS (Hypertext-as-the-engine-of-application-state) and including links in XML or HTML responses, so if you're using JSON it's probably more REST-like as opposed to full-blown REST. At the end of the day, it's all a matter of preference; just try to use whatever will fit the needs of the application's users in a way that's somewhat self-documenting and intuitive.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm having an issue where the contents of an uploaded file, via a FileField, are lost when the user resubmits form. I'm guessing the easy answer is to force the user to re-upload the file however I was wondering if there might be a workaround that can avoid having the user re-upload.
As #dirn stated, that is the nature of file uploads. You have two options to get around this.
Save the uploaded file temporarily (especially if its large) while you prompt the user to fix the input error (as suggested by #dirn). This would require extra logic to purge files (assuming the user decides they don't want to submit form anymore or they go to a different page, etc)
Validate your form using javascript so that the file only uploads when the form is actually valid (wtforms doesn't really help you much with this option)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am learning about Django & Python from past two weeks.though, my reading i came across models.py & forms.py. structure of both this is almost same. can anyone explain me whats the difference between them?
I also want to know where do i have to write the (<form> </form>) code. I mean in any html file or *.py file or where?
They are indeed very different in concept, albeit they can look similar. Let me explain:
Models define your business objects and data structures. They are the "entities" of the application wich have to be persisted in the database. Since it's a definition of the objects and their attributes, you define "fields". They represent the data structure and persistence of the app.
Forms are meant to make easier to get input from the user, validate data, render html and recover values supplied by the user. They also have fields but you have to note they don't map to a database and they don't represent an entity. They represent the "inputs" of the app.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
to get posts for a user:
GET http://test.com/users/123/posts or GET http://test.com/posts?user_id=123
to get new posts count:
GET http://test.com/posts/count/new or http://test.com/new_posts_count or others?
This is a good read: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api.
And in terms of the two formats you suggested: I prefer the former.
Doesn't matter from a REST point of view (REST doesn't define URI structure). The client should not know the URL structure before hand so technically it doesn't matter to the client either.
I personally prefer the first style as I think it makes more sense when you have a resource hierarchy. It also allows a client to move back up a URI by simply chopping off the end resource, similar to how you can go back up a directory on a file system by simply clicking the parent button.
But there is no "right answer" to this from a REST point of view. REST is concerned with the transfer of state of resources, not the resource hierarchy or URI definition.