11–20 of 68 posts
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.
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 .
Earlier quoted context omitted.
Which is basically stupid by itself, as you simply expose your internal data structures without control or thought.
care to explain?
When you publish internals, you only cement your implementation so you can't change that easily later (e.g. when you realize how crappy it was at first), and you even need to pay for that drawback with ease of use of your API (API's user would need to understand the system he talks with). It's a lose-lose deal.
I always miss DJRF when using languages other than Python
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.
I always miss DJRF when using languages other than Python
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.
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 .
Earlier quoted context omitted.
care to explain?
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…
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.