Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django REST framework 3.5

django-rest-framework.org

Post reply on HN
Print view View original

31–40 of 68 posts

Re: Django REST framework 3.5

#31

Post by dopeboy »

alexbecker wrote: post #30

I like DRF, but I think its allow-by-default mentality is a security risk. If you use it, keep in mind that: * 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 especi…

If you want to get even more granular, I would suggest using the mixins. I almost never use the broad viewsets anymore.

Example:

  class FooViewset(  
          mixins.CreateModelMixin,  
          mixins.ListModelMixin,  
          mixins.DestroyModelMixin,  
          mixins.RetrieveModelMixin,  
          viewsets.GenericViewSet)
Subtract as necessary.

Re: Django REST framework 3.5

#32

Post by alexbecker »

dopeboy wrote: post #31
alexbecker wrote: post #30

I like DRF, but I think its allow-by-default mentality is a security risk. If you use it, keep in mind that: * 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 especi…

If you want to get even more granular, I would suggest using the mixins. I almost never use the broad viewsets anymore. Example: class FooViewset( mixins.CreateModelMixin, mixins.ListModelMixin, mixins.DestroyModelMixin, mixins.RetrieveModelMixin, viewsets.GenericViewSet) Subtract as necessary.

This is a good way to control what methods are allowed on the ViewSet, but still doesn't address the problem of fields being writable by default when the ViewSet allows writing.

Re: Django REST framework 3.5

#33

Post by misiti3780 »

ralmidani wrote: post #21
misiti3780 wrote: post #15

Earlier quoted context omitted.

isnt DRF built into rails basically (never used rails)

Last time I checked, in Rails there's no Controller class that has all the built-in functionality of a DRF ViewSet. For example, you still have to perform the DB queries for every action yourself, rather than just define a queryset and serializer for the entire class and let the framework handle the rest (no pun intended).

i was under the impression that you can add :json to your controllers and they return "serialized" data.

Re: Django REST framework 3.5

#34

Post by ralmidani »

misiti3780 wrote: post #33
ralmidani wrote: post #21

Earlier quoted context omitted.

Last time I checked, in Rails there's no Controller class that has all the built-in functionality of a DRF ViewSet. For example, you still have to perform the DB queries for every action yourself, rather than just define a queryset and serializer for the entire class and let the framework handle the rest (no pun intended).

i was under the impression that you can add :json to your controllers and they return "serialized" data.

Someone please correct me if I'm wrong, but my understanding is in Rails you still need to define every action in the controller. With DRF, you just inherit from a ModelViewSet, declare the queryset and serializer on the class (or have methods return them if you need custom behavior), and you're good to go. It makes prototyping so much easier, and adding filters and permissions is very straightforward.

Re: Django REST framework 3.5

#35

Post by Cyph0n »

aikah wrote: post #17
jpdlla wrote: post #10

Earlier quoted context omitted.

This. I've recently been working with a large project using Node. I find myself constantly thinking about how I'd build it if I were using DRF.

> This. I've recently been working with a large project using Node. I find myself constantly thinking about how I'd build it if I were using DRF. You wouldn't need to think about promises or callbacks at first place, which would make things way easier. That's the main reason I gave up NodeJS for Go when working with APIs. Async programming is noise. CSP is a better paradigm.

Scala, Akka, and Play say hi!

Re: Django REST framework 3.5

#36

Post by misterbowfinger »

dopeboy wrote: post #5

One metric that I'll measure a framework by is the likelihood of finding an answer to a query that is not articulated in the concepts and terms used by the framework. This is especially useful when starting out. DRF scores well here. It's designed in an intuitive way. The healthy community around it is a big plus as well. Can't count the number of times I've come across a SO article that had updated answers for the l…

> One metric that I'll measure a framework by is the likelihood of finding an answer to a query that is not articulated in the concepts and terms used by the framework.

It's also important to measure the likelihood to have to find an answer in the first place. There are vibrant communities around many frameworks, but it doesn't make them all good.

Speaking as someone who went from DRF -> Rails -> back to DRF, I can say that DRF is sufficiently confusing to understand and get started with. The problem partially exists within Django itself, but DRF doesn't exactly help. It can feel like pulling teeth to create a simple API with DRF. And, as the another HN comment explains, DRF does a ton of "opt-in" work that can end up doing more than you intended.

My biggest gripe with DRF is how coupled it is to the Django ORM. All of the nice ViewSets are only useful if you have cookie-cutter Django models, but we all end up changing them.

I tend to enjoy working with Ruby Grape APIs:

https://github.com/ruby-grape/grape#basic-usage

No need to deal with 100 types of ViewSets, Serializers, Renderers, Parsers, and so on. You just need to understand that data is being passed back and forth. If you need something more complicated, just add it yourself.

I wish Python had something similar. Something that's between Django & Flask in terms of complexity.

Re: Django REST framework 3.5

#37

Post by Daishiman »

lcnmrn wrote: post #20

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.

Assuming you don't want to transform data, provide your own custom serializers, provide pluggable auth modules and authentication methods, CRUD viewsets, accepting and receiving multiple response types, then yeah.

Re: Django REST framework 3.5

#38

Post by [deleted] »

alexbecker wrote: post #32
dopeboy wrote: post #31

Earlier quoted context omitted.

If you want to get even more granular, I would suggest using the mixins. I almost never use the broad viewsets anymore. Example: class FooViewset( mixins.CreateModelMixin, mixins.ListModelMixin, mixins.DestroyModelMixin, mixins.RetrieveModelMixin, viewsets.GenericViewSet) Subtract as necessary.

This is a good way to control what methods are allowed on the ViewSet, but still doesn't address the problem of fields being writable by default when the ViewSet allows writing.

[deleted]

Re: Django REST framework 3.5

#39

Post by chc »

alexbecker wrote: post #32
dopeboy wrote: post #31

Earlier quoted context omitted.

If you want to get even more granular, I would suggest using the mixins. I almost never use the broad viewsets anymore. Example: class FooViewset( mixins.CreateModelMixin, mixins.ListModelMixin, mixins.DestroyModelMixin, mixins.RetrieveModelMixin, viewsets.GenericViewSet) Subtract as necessary.

This is a good way to control what methods are allowed on the ViewSet, but still doesn't address the problem of fields being writable by default when the ViewSet allows writing.

This seems like the expected behavior. If allowing for writing didn't actually allow you to write anything, that would be pretty strange, wouldn't it? Or do I misunderstand?

Re: Django REST framework 3.5

#40

Post by alexbecker »

chc wrote: post #39
alexbecker wrote: post #32

Earlier quoted context omitted.

This is a good way to control what methods are allowed on the ViewSet, but still doesn't address the problem of fields being writable by default when the ViewSet allows writing.

This seems like the expected behavior. If allowing for writing didn't actually allow you to write anything, that would be pretty strange, wouldn't it? Or do I misunderstand?

You may want to expose some fields that you don't allow changing, such as what account owns the resource. When fields are writable by default, it is easy for someone to miss that they've made a field writable when they just meant to expose it for reading.
Post reply on HN