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

41–50 of 68 posts

Re: Django REST framework 3.5

#41

Post by mastazi »

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.

Your comment is being downvoted because DRF clearly does a whole lot more than just serialising the response dictionary or adding pagination, you should really have a look at the documentation.

However, I still think that Django should have something like the "JSONResponse mixin example"[1] built-in by default; sometimes you are building a product which is not an API but you still need the occasional RESTful endpoint and, in those cases, something like DRF would be overkill.

[1] https://docs.djangoproject.com/en/1.10/topics/class-based-vi...

Re: Django REST framework 3.5

#42

Post by Kpourdeilami »

alexbecker wrote: post #40
chc wrote: post #39

Earlier quoted context omitted.

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.

I think it's better to define field specific read/write permissions through the serializers. In the serializer's Meta class, you can define a readonly_fields tuple containing the string names of the read only fields

Re: Django REST framework 3.5

#43

Post by findjashua »

Cyph0n wrote: post #35
aikah wrote: post #17

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. 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!

Don't you still need Futures for async stuff in order to not block the thread, or is each request handled by a lightweight 'fiber' (erlang process/goroutine)?

Re: Django REST framework 3.5

#44

Post by vmsp »

misterbowfinger wrote: post #36
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 s…

Falcon maybe?

Re: Django REST framework 3.5

#45

Post by Rotareti »

vmsp wrote: post #44
misterbowfinger wrote: post #36

Earlier quoted context omitted.

> 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 s…

Falcon maybe?

Some more options:

Eve: https://github.com/nicolaiarocci/eve Hug: https://github.com/timothycrosley/hug flask-restful: https://github.com/flask-restful/flask-restful

Re: Django REST framework 3.5

#46

Post by ralmidani »

mastazi wrote: post #41
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.

Your comment is being downvoted because DRF clearly does a whole lot more than just serialising the response dictionary or adding pagination, you should really have a look at the documentation. However, I still think that Django should have something like the "JSONResponse mixin example"[1] built-in by default; sometimes you are building a product which is not an API but you still need the occasional RESTful endpoint…

You could always import DRF's serializers and parsers/generators without committing to the entire framework.

Django does plan on bringing DRF's content negotiation into the main framework:

https://www.djangoproject.com/weblog/2015/dec/11/django-awar...

Re: Django REST framework 3.5

#47

Post by ubernostrum »

elcct wrote: post #16

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.

The intro tutorial tends to show you the low-level/more-code-but-infinitely-customizable way a thing really works, and then once you understand that, introduce the convenient abstractions on top of it that make common cases simpler/less code. So keep reading :)

Re: Django REST framework 3.5

#48

Post by Cyph0n »

findjashua wrote: post #43
Cyph0n wrote: post #35

Earlier quoted context omitted.

Scala, Akka, and Play say hi!

Don't you still need Futures for async stuff in order to not block the thread, or is each request handled by a lightweight 'fiber' (erlang process/goroutine)?

That's correct, blocking operations within an actor need to be wrapped in a Future[1]. But Akka itself can be extremely performant if the bulk of your processing is non-blocking. Any non-blocking or long-running operations should be executed in a separate thread pool (if there are many), or just a separate thread.

[1]: http://doc.akka.io/docs/akka/2.4/general/actor-systems.html#...

Re: Django REST framework 3.5

#49

Post by Alex3917 »

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…

> I like DRF, but I think its allow-by-default mentality is a security risk.

Completely agree. But DRF is useful even if you don't use any of the serializers. E.g. you can just use it to handle auth, requests, and responses, and then validate things by hand and save them directly to the Django model. You still pretty much need serializers when validating image files because you can't trigger the Django code to do this by saving to the model directly, but for everything else it's often more readable just to serialize and deserialize by hand.

Post reply on HN