21–30 of 68 posts
I always miss DJRF when using languages other than Python
isnt DRF built into rails basically (never used rails)
There’s no need for a framework since you can do: values = User.objects.all().values('id', 'username') results = json.dumps(values) …or use the builtin JSON serializer. You can also use Paginator to paginate the results.
There’s no need for a framework since you can do: values = User.objects.all().values('id', 'username') results = json.dumps(values) …or use the builtin JSON serializer. You can also use Paginator to paginate the results.
Earlier quoted context omitted.
Data structures used internally for processing are something totally different than data structures used for communication with outside world. Usually you don't want to expose internals with public API, and even when you do, you want to be very selective about what is shown and how. When you publish internals, you only cement your implementation so you can't change that easily later (e.g. when you realize how crappy…
I agree, I find doing this with DRF very easy and had the opposite with TastyPie doing stuff I did not want or need. Having some ORM integration is nice; there are a number of situations where it's easy to use your ORM safely and get stuff done very quickly (eg. basic CRUD stuff for instance)
I have a question about http://www.django-rest-framework.org/tutorial/2-requests-and... Is it a good practice to handle all verbs in the function dealing with the particular request as shown in the example? I think for a real world scenario that would be a mess to read, but for a less experienced developer this could hint that such approach is alright and result in a less readable code base in the future.
For people who are unfamiliar, there is also Tastypie. I find it's Model centric approach a whole lot nicer to work with then Django-Rest .
Which is basically stupid by itself, as you simply expose your internal data structures without control or thought.
I have a question about http://www.django-rest-framework.org/tutorial/2-requests-and... Is it a good practice to handle all verbs in the function dealing with the particular request as shown in the example? I think for a real world scenario that would be a mess to read, but for a less experienced developer this could hint that such approach is alright and result in a less readable code base in the future.
Basically, you will 1. split verbs to different methods of one class and 2. you can not implement verbs you are not going to allow (you can of course do that also with the functional style you see in the link you posted)
I have a question about http://www.django-rest-framework.org/tutorial/2-requests-and... Is it a good practice to handle all verbs in the function dealing with the particular request as shown in the example? I think for a real world scenario that would be a mess to read, but for a less experienced developer this could hint that such approach is alright and result in a less readable code base in the future.
If you proceed with the tutorial it is going to show you what I consider is the cleanest way to go for views in django rest framework (ViewSets, coupled with the routers, part 6 of the tutorial). Basically, you will 1. split verbs to different methods of one class and 2. you can not implement verbs you are not going to allow (you can of course do that also with the functional style you see in the link you posted)
For people who are unfamiliar, there is also Tastypie. I find it's Model centric approach a whole lot nicer to work with then Django-Rest .
* ModelViewSet is read/write, you should use the more verbose ReadOnlyModelViewSet until you know you want to allow writing.
* Fields specified in the "fields" member are read/write by default. You have to explicitly declare the field on the ViewSet and pass "readonly=true" to make it read-only. This is especially dangerous for ForeignKey fields, which can be used to change object ownership if you aren't careful.
When I was responsible for a DRF-based API I wrote some custom Fields and ViewSets to use safer defaults, and I recommend others do the same.