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

51–60 of 68 posts

Re: Django REST framework 3.5

#51

Post by qnrq »

Kpourdeilami wrote: post #42
alexbecker wrote: post #40

Earlier quoted context omitted.

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

You can also route only read-only methods in urls.py, for example via:

    url(
        r'path/$',
        TheModelViewSetView.as_view({"get": "list"}),
        name="thename"
    )
or "retrieve" instead of "list" for a route which includes PK.

This of course makes the entire path read-only so it's not a way to make some fields writable and others not.

Re: Django REST framework 3.5

#52

Post by sandGorgon »

ralmidani wrote: post #9

When I started flirting with Ruby and Rails for building a web app backed by a JSON API, DRF is what convinced me to stick with Django. It has a ridiculous amount of built-in functionality, but without making it hard to customize your API. If you haven't used DRF, you really owe it to yourself to give it a try. I can't wait to see support for real-time views. Is that in the cards for DRF 3.6?

drf and ruby on rails are apples to oranges. you should probably compare django and rails.

drf is usually compared to sinatra.

Re: Django REST framework 3.5

#54

Post by theptip »

Anyone been using the new(ish) schema generation features? Sounds useful to be able to generate client libraries from the API spec (e.g. DRF => swagger => JS library), but I haven't felt compelled to do so. Any other use-cases that are paying dividends?

Re: Django REST framework 3.5

#55

Post by pmontra »

ralmidani wrote: post #34
misiti3780 wrote: post #33

Earlier quoted context omitted.

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.

You are correct.

Maybe the DRF for Ruby is grape https://github.com/ruby-grape/grape/blob/master/README.md but I never used it. I just fill in the standard scaffolded REST methods in the controllers with queries and write json views (Rails and Django have different terms and concepts, MVC vs MVT.)

Re: Django REST framework 3.5

#56

Post by rtpg »

Kpourdeilami wrote: post #42
alexbecker wrote: post #40

Earlier quoted context omitted.

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

yeah, I think they're saying instead of having the Meta fields list create writable fields by default, it should be read-only by default, after which you could add a "writable_fields" list

Re: Django REST framework 3.5

#57

Post by rtpg »

theptip wrote: post #54

Anyone been using the new(ish) schema generation features? Sounds useful to be able to generate client libraries from the API spec (e.g. DRF => swagger => JS library), but I haven't felt compelled to do so. Any other use-cases that are paying dividends?

I was thinking about using it to auto-generate documentation, but I found writing some ad-hoc tooling turned out to be more straightforward and flexible.

Re: Django REST framework 3.5

#58

Post by andybak »

snippet22 wrote: post #50

I just stopped from the js community to the Python one cause of js fatigue and the first thing I learned is Django restful APIs and now this happens....

Now what happens? A well documented and almost entirely backwards compatible release of one of Django's leading 3rd party additions?

Re: Django REST framework 3.5

#59

Post by ergo14 »

ralmidani wrote: post #9

When I started flirting with Ruby and Rails for building a web app backed by a JSON API, DRF is what convinced me to stick with Django. It has a ridiculous amount of built-in functionality, but without making it hard to customize your API. If you haven't used DRF, you really owe it to yourself to give it a try. I can't wait to see support for real-time views. Is that in the cards for DRF 3.6?

I think that for API building pyramid is the way to go - it has a lot of built in goodies to support api building + there are things like cornice by mozilla or pyramid_swagger.

Re: Django REST framework 3.5

#60

Post by postcarnival »

ralmidani wrote: post #11

I use Django + DRF along with Ember, and love the combination. All the new schema generation functionality is interesting. It's probably just a matter of time before someone builds a tool that reads the schema generated by Django, and syncs the Ember models with it. That's currently one of the drawbacks of using separate frameworks (and languages) for the client and server.

I'm using that stack for two fairly large projects and loving it... I use the ember-django-adapter to translate data on the client side (previously had used drf json-api).. so far it's not too much hassle to build the ember models as needed but I see what you're saying..
Post reply on HN